Idea to Product Sequencer

Measured conclusion: Deep-tested. L2 outcome: tools_ok.

Rule-based product method: scores an idea, finds its riskiest assumption, sequences the build.

Add to your agent

Copy this into your MCP client config:

{
  "mcpServers": {
    "Idea to Product Sequencer": {
      "url": "https://mcp.modernmustardseed.com/idea-sequencer",
      "transport": "streamable-http"
    }
  }
}

Measured tools (7)

• classify_idea read-only

  Classify a product or business idea with fixed rules (no AI model): one of 10 product types and 9 buyer types with the words that matched, a 0 to 100 risk score on each of 10 assumptions (problem, buyer access, willingness to pay, solution fit, feasibility, retention, supply, regulatory, unit economics, operator capacity) with every rule that moved each score, the riskiest assumption written as a sentence a test can prove wrong, red flags, the stage of the Idea to Product method it is in, the build rules for its type, and the cheapest validation test for this week with pass and kill lines. Evidence already gathered (interviews, signups, deposits, payments) lowers risk along a fixed evidence ladder. The same input always gives the same answer.

  Parameters:

  • idea (required) — string — The idea in plain words: what it does and for whom.
  • billing — string — one_time, monthly, annual or per_use. Default one_time.
  • evidence — array — What has been learned so far.
  • who_pays — string — The person who pays, by role and niche, for example "owners of 2 to 10 truck plumbing companies".
  • who_uses — string — The person who uses it, if different from who pays.
  • price_usd — number — Intended price in US dollars.
  • buyer_type — string — Override the detected buyer type.
  • start_date — string — ISO date the work starts. Default today (UTC).
  • has_audience — boolean — True if there is an existing list, following or customer base to test with.
  • product_type — string — Override the detected product type.
  • audience_size — integer
  • has_prototype — boolean — True if a working version is already in users' hands.
  • days_available — integer — Days until a decision is needed. Default 7.
  • test_budget_usd — number — Cash available for the validation test. Default 0.
  • reachable_buyers — integer — How many named buyers can be contacted this week.
  • technical_builder — boolean — False if nobody on the team can build the hardest part. Default true.
  • current_alternative — string — What they use or do about the problem today, for example "spreadsheets and texts", "Jobber", or "nothing".
  • runs_another_business — boolean — True if the founder is building this alongside a business they already run.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• validation_plan read-only

  Pick the cheapest test that can prove one assumption about an idea wrong within the days available, from a library of 18 named tests (for example Five Past-Behavior Interviews, Pay Link Pre-sale, Smoke Test Landing Page, Letter of Intent Round, Concierge MVP, Wizard of Oz, Feasibility Spike, Hand-Seeded Supply, Unit Cost Teardown, Regulatory Read and One Call). Tests are filtered by the buyer type, the price, the audience, reachable buyers, budget and whether someone can build, then ranked by strength of evidence against cost and days. Returns the sample, steps, a pass line, a kill line and an inconclusive rule set before the test runs, the decision date, a backup test, and every ruled-out test with the reason. Defaults to the riskiest assumption; pass assumption to choose another.

  Parameters:

  • idea (required) — string — The idea in plain words: what it does and for whom.
  • billing — string — one_time, monthly, annual or per_use. Default one_time.
  • evidence — array — What has been learned so far.
  • who_pays — string — The person who pays, by role and niche, for example "owners of 2 to 10 truck plumbing companies".
  • who_uses — string — The person who uses it, if different from who pays.
  • price_usd — number — Intended price in US dollars.
  • assumption — string — The assumption to test. Default: the riskiest one the classifier finds.
  • buyer_type — string — Override the detected buyer type.
  • start_date — string — ISO date the work starts. Default today (UTC).
  • has_audience — boolean — True if there is an existing list, following or customer base to test with.
  • product_type — string — Override the detected product type.
  • audience_size — integer
  • has_prototype — boolean — True if a working version is already in users' hands.
  • days_available — integer — Days until a decision is needed. Default 7.
  • test_budget_usd — number — Cash available for the validation test. Default 0.
  • reachable_buyers — integer — How many named buyers can be contacted this week.
  • technical_builder — boolean — False if nobody on the team can build the hardest part. Default true.
  • current_alternative — string — What they use or do about the problem today, for example "spreadsheets and texts", "Jobber", or "nothing".
  • runs_another_business — boolean — True if the founder is building this alongside a business they already run.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• cut_mvp read-only

  Sort a feature list into must, should and not now using 15 explicit rules on each feature's tags (core_job, revenue, compliance, trust_safety, onboarding, measurement, retention, integration, automation, admin, growth, analytics, customization, platform, scale, delight), whether it could be done by hand at first, and how many buyers asked for it. Dependencies of a must become must. Should-haves fill the build window by value per effort point in dependency order. Returns each feature with its tier, the rule and the reason, effort totals against capacity, and when the must-haves do not fit, the specific cuts that would make them fit. Rejects duplicate ids, unknown dependencies and cycles with the chain named.

  Parameters:

  • features (required) — array
  • builders — integer — People building in parallel. Default 1.
  • build_weeks — integer — Build window in weeks. Default 6.
  • points_per_week — number — Effort points one builder clears in a week. Default 5.
  • charge_at_launch — boolean — True if buyers pay from launch. Default true.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• sequence_build read-only

  Turn a feature list with dependencies into a dated build plan: applies the MVP cut, orders tasks by dependency, schedules them across the given number of builders on working days (weekends skipped), computes the critical path and each task's slack, adds the method's own tasks (record the success metric, take payment, launch kit, Hand Off) where missing, and dates the milestones: first core job end to end, MVP in real users' hands, launch, success metric review, and Hand Off. Every plan carries a success metric and a review date; a default per product type is used and flagged when none is given.

  Parameters:

  • features (required) — array
  • scope — string — "mvp": must-haves only. "launch" (default): must-haves plus should-haves that fit the window. "all": everything.
  • builders — integer — People building in parallel. Default 1.
  • start_date — string — ISO date the build starts. Default today (UTC). Weekends are skipped.
  • build_weeks — integer — Build window in weeks. Default 6.
  • product_type — string — Used for the default success metric when none is given.
  • success_metric — object — The number that decides success, its target, and how many days after launch to read it.
  • points_per_week — number — Effort points one builder clears in a week. Default 5.
  • charge_at_launch — boolean — True if buyers pay from launch. Default true.
  • validate_first_days — integer — Working days of validation before the build starts. Default 0.
  • include_method_tasks — boolean — Add the method's own tasks: metric recording, payment, launch kit and Hand Off. Default true.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• kill_or_continue read-only

  Make a push, iterate, park or kill call on 1 to 12 products from their metrics (target, actual, kill line, must-hit), evidence, stage, review date, last activity, and monthly revenue and cost, using 10 named decision rules: a must-hit metric past its kill line on the review date kills; a weighted score under 30 on the review date kills; more than 45 days idle parks; revenue under cost and falling kills or forces a price or cost change; 80 or more with the stage gate evidence pushes. Returns each call with its score, rule, reason, next action, next review date and what would flip it, then portfolio notes. Money and time already spent are recorded and deliberately ignored.

  Parameters:

  • products (required) — array
  • as_of — string — Review as of this date. Default today (UTC).
  • builders — integer — People available to build across the portfolio.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• build_scope_and_sequence read-only

  Run the full Idea to Product method on one idea and its feature list and return a Scope and Sequence plan as a Markdown document, followed by a short JSON summary. The document covers the problem and buyer, the riskiest assumption with its risk table, this week's validation test with pass and kill lines, red flags, the MVP cut (must, should, not now, with reasons), the build sequence with builders and dates, milestones through Hand Off, the launch plan and success metric, kill criteria written before the work, build rules for the product type, and a Hand Off checklist. When there is no commitment-level evidence yet, the build is scheduled to start after the test's decision date.

  Parameters:

  • idea (required) — string — The idea in plain words: what it does and for whom.
  • features (required) — array
  • scope — string
  • title — string
  • billing — string — one_time, monthly, annual or per_use. Default one_time.
  • builders — integer — People building in parallel. Default 1.
  • evidence — array — What has been learned so far.
  • who_pays — string — The person who pays, by role and niche, for example "owners of 2 to 10 truck plumbing companies".
  • who_uses — string — The person who uses it, if different from who pays.
  • price_usd — number — Intended price in US dollars.
  • buyer_type — string — Override the detected buyer type.
  • start_date — string — ISO date the work starts. Default today (UTC).
  • build_weeks — integer — Build window in weeks. Default 6.
  • has_audience — boolean — True if there is an existing list, following or customer base to test with.
  • product_type — string — Override the detected product type.
  • audience_size — integer
  • has_prototype — boolean — True if a working version is already in users' hands.
  • days_available — integer — Days until a decision is needed. Default 7.
  • success_metric — object
  • points_per_week — number — Effort points one builder clears in a week. Default 5.
  • test_budget_usd — number — Cash available for the validation test. Default 0.
  • charge_at_launch — boolean — True if buyers pay from launch. Default true.
  • reachable_buyers — integer — How many named buyers can be contacted this week.
  • technical_builder — boolean — False if nobody on the team can build the hardest part. Default true.
  • current_alternative — string — What they use or do about the problem today, for example "spreadsheets and texts", "Jobber", or "nothing".
  • runs_another_business — boolean — True if the founder is building this alongside a business they already run.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• explain_method read-only

  Return one of the method's reference tables: the four stages and their exit gates, the 10 assumptions, the evidence ladder, the 18 validation tests, the MVP cut rules, the feature tags, the 10 product types with their risk priors and build rules, the 9 buyer types, the decision rules, or the risk scoring rules. Static reference, no computation on user data.

  Parameters:

  • topic (required) — string — stages, assumptions, evidence_ladder, validation_tests, mvp_rules, feature_tags, product_types, buyer_types, decision_rules or risk_rules.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

Publisher website

Measured by MCPYP probing. Untested fields are omitted, never estimated. Listing is always free; MCPYP never proxies calls or stores user tokens.