MCP connector for Claude

Idea to Product Sequencer: test the riskiest thing first.

The sequencer applies the Idea to Product method (Scope and Sequence, Build and Ship, Launch, Hand Off) as fixed rules. It reads an idea into a fixed taxonomy, scores ten assumptions with named rules, picks the one most likely to sink it, chooses the cheapest test that could prove it wrong this week with the pass and kill lines written in advance, cuts the feature list to an MVP, dates the build, and later makes the push, park or kill call against the numbers. No model guesses anything: every answer traces to a rule or a number in the method tables below, and the same input always gives the same plan.

Connector URL

https://mcp.modernmustardseed.com/idea-sequencer

Streamable HTTP. No sign-in. Every tool is read-only, deterministic, and makes no network calls.

Connect it

  1. In Claude, open Settings, then Connectors.
  2. Choose Add custom connector, paste https://mcp.modernmustardseed.com/idea-sequencer, and save. No account or key is needed.
  3. Describe the idea in a chat, or start one of the guided sessions from the prompt menu.

In Claude Code: claude mcp add --transport http idea-sequencer https://mcp.modernmustardseed.com/idea-sequencer

Try these

The tools

classify_idea

Classify an idea

Reads the idea into a fixed taxonomy: one of 10 product types and 9 buyer types, a 0 to 100 risk score on each of 10 assumptions with every rule that moved it, the riskiest assumption written as a sentence a test can prove wrong, red flags, where the idea sits in the four-stage method, the build rules for its type, and the cheapest test for this week.

Inputs: idea (required); who_pays, who_uses, current_alternative, price_usd, billing, product_type, buyer_type, evidence, has_audience, audience_size, has_prototype, technical_builder, runs_another_business, reachable_buyers, test_budget_usd, days_available, start_date.

validation_plan

Plan a validation test

Picks the cheapest test that can prove one assumption wrong inside the days available, from a library of 18 named tests. Returns the sample, the steps, the pass line, the kill line and the inconclusive rule, all written before the test runs, a decision date, a backup test, and every test it ruled out with the reason.

Inputs: The same fields as classify_idea, plus assumption (optional; default is the riskiest).

cut_mvp

Cut an MVP

Sorts a tagged feature list into must, should and not now by 15 explicit rules, closes the cut over dependencies, fills the build window with should-haves by value per point, and when the must-haves do not fit, names the exact cuts that would make them fit.

Inputs: features (required: id, name, tags, depends_on, effort or points, manual_alternative, requested_by); builders, points_per_week, build_weeks, charge_at_launch.

sequence_build

Sequence the build

Orders the features by dependency, schedules them across the builders on working days, finds the critical path and the slack on every task, adds the method tasks (success metric, payment, launch kit, Hand Off), and dates the milestones from first core job to Hand Off, with the success metric review date.

Inputs: features (required); builders, points_per_week, build_weeks, start_date, scope (mvp, launch or all), include_method_tasks, product_type, success_metric, validate_first_days.

kill_or_continue

Kill or continue

Scores up to 12 products against targets and kill lines set in advance, checks the evidence against the gate for each stage, and makes the call (push, iterate, park or kill) by named rules, with the next action, the next review date, and what would change the call. Money and time already spent are accepted and deliberately ignored.

Inputs: products (required: name, stage, metrics with target and actual, evidence, review_date, last_activity, monthly revenue and cost, trend); builders; as_of.

build_scope_and_sequence

Write a Scope and Sequence

Runs the whole method in one pass and writes the plan as a Markdown document: problem and buyer, riskiest assumption, this week's test, red flags, the MVP cut, the build sequence, dated milestones, the launch plan and success metric, kill criteria, build rules and the Hand Off checklist.

Inputs: The classify_idea fields plus features (required); title, builders, points_per_week, build_weeks, charge_at_launch, scope, success_metric.

explain_method

Explain the method

Returns any of the method's tables as reference: stages, assumptions, the evidence ladder, the validation test library, MVP rules, feature tags, product types, buyer types, decision rules and risk rules.

Inputs: topic (required).

Guided sessions

The connector also offers four prompts, which appear in Claude's prompt menu once it is connected.

The method

Ten assumptions

Every idea is scored on all ten, starting from a prior for its product type, adjusted by its buyer type and by signals in the description (regulated topics, hard technology, price, the current alternative, a payer who is not the user), then lowered by evidence. The highest residual risk is tested first, except that a regulatory score of 70 or more always goes first, and an assumption that depends on a nearly as risky one waits for it.

The evidence ladder

Evidence counts for more the more it costs the buyer to give. A compliment counts for nothing.

The validation test library

MVP cut rules

Decision rules

Product types

Data sources and licenses

None outside our server. The method tables, rules and test library are our own work, published here in full. The tools compute only on the arguments Claude sends and read no outside website, database or API.

Limits

Troubleshooting

The product type or buyer is wrong
Pass product_type and buyer_type explicitly. who_pays is read first for the buyer, so naming the payer by role and niche fixes most cases.
“No test in the library can test...”
Every eligible test needs something the inputs ruled out. The message lists each test and its reason; supply a price, reachable buyers, a budget or a builder and call again.
“Dependency cycle”
Two or more features wait on each other. The message names the chain; remove one dependency.
The plan uses a success metric I did not give
Every plan needs a metric and a date, so a default for the product type is used and flagged. Pass success_metric to replace it.

For reviewers

No account, key or setup is needed. Add the connector URL above, then:

  1. classify_idea with {"idea": "A marketplace that connects homeowners in Kalispell with snow plow operators who have open slots after a storm, with a booking fee per job.", "who_pays": "homeowners", "current_alternative": "calling plow guys from a Facebook group", "price_usd": 15, "billing": "per_use", "reachable_buyers": 80} returns marketplace, consumer, supply as the riskiest assumption, the cold start flag, and the Hand-Seeded Supply test.
  2. validation_plan with {"idea": "Bookkeeping cleanup for contractors behind on their books.", "who_pays": "owners of construction companies", "price_usd": 1500, "assumption": "willingness_to_pay", "reachable_buyers": 30} returns the Pay Link Pre-sale with a pass line of 2 of 20.
  3. cut_mvp and sequence_build with {"features": [{"id": "auth", "name": "Sign in", "tags": ["trust_safety"], "effort": "s"}, {"id": "quote", "name": "Quote builder", "tags": ["core_job"], "depends_on": ["auth"], "effort": "l"}, {"id": "themes", "name": "Themes", "tags": ["customization"]}], "start_date": "2026-11-02"} return the cut and a dated plan.
  4. kill_or_continue with {"products": [{"name": "A", "stage": "launched", "review_date": "2026-10-01", "metrics": [{"name": "paying accounts", "target": 10, "actual": 1, "must_hit": true}], "already_spent_usd": 40000}]} returns kill by rule K1 and lists the spend as ignored.
  5. explain_method with {"topic": "validation_tests"} returns the test library.
  6. Errors: a feature depending on an id not in the list, or two features depending on each other, each return a specific message naming the ids.

Support and security

Questions, problems and security reports go to sarah@modernmustardseed.com. A machine-readable contact is at /.well-known/security.txt. How we handle data is in the privacy policy.