should small tools bother with MCP: decision framework

TL;DR

Build the MCP server if agents already want your tool and your API surface is small and stable; skip it if you are still finding users or the API changes monthly. The cost is not the first build, it is the maintenance: every API change becomes a tool-schema change, a changelog entry, and three registry updates. Score the decision on demand, fit, and cost, and let the worksheet say no.

should small tools bother with MCP: decision framework

Use this when

• You maintain a small devtool and keep hearing "do you have an MCP server"
• Your roadmap is crowded and MCP is competing with real features
• Your API is still changing fast and you fear version churn
• You want a defensible no (or yes) to show a cofounder or boss
• You are comparing MCP against docs, API, and CLI investments

Not for this skill when

• You already decided yes and need the build and test guides
• The tool is large with an established agent user base (the answer is yes, skip the worksheet)
• The question is MCP vs API vs CLI as distribution strategy (different skill)
• You need a market forecast for MCP adoption generally

Steps

1. Check for real demand, not vibes. Search your issues, support threads, and community for agents or users asking for MCP access by name. Three independent asks in a quarter is a signal; one tweet is not.

   demand evidence:
   [ ] issue or thread 1: [link or id]
   [ ] issue or thread 2: [link or id]
   [ ] issue or thread 3: [link or id]

Expected output: dated evidence or an honest empty list. Success check: you can quote the asks instead of gesturing at them.

1. Score your API surface for MCP fit. Small, stable, read-heavy surfaces fit beautifully; huge, chatty, or constantly-changing surfaces become a maintenance treadmill. Count your endpoints and rate how often their shapes change.

   endpoints: [count]  shape changes per quarter: [count]
   reads vs writes: [mostly reads | mixed | mostly writes]

Expected output: a fit judgment in one line. Success check: fewer than ~20 endpoints and rare shape changes means good fit.

1. Price the maintenance honestly. Budget one day per quarter for schema updates, registry listing syncs, and answering agent-behavior questions, plus the initial build week. If that day does not exist, the server will rot and a rotten listing is worse than no listing.

   build cost: [days]  quarterly upkeep: [days]  owner: [name]

Expected output: a named owner and a real budget. Success check: the owner agrees they own it, in writing.

1. Run the worksheet and take the answer seriously. Add it up: demand (0 to 2), fit (0 to 2), capacity (0 to 2). Six or more means build now; three or fewer means skip and revisit in two quarters; four to five means ship a minimal read-only server and see.

   demand [0-2] + fit [0-2] + capacity [0-2] = [total]
   6+: build  4-5: minimal read-only pilot  <=3: skip, revisit later

Expected output: a number and a decision. Success check: you could defend the decision to a skeptical cofounder with the worksheet alone.

1. If the answer is no, write the no down publicly. A short "we are not building an MCP server yet, here is why and what would change our mind" note in your docs or discussions stops the question from recurring every month and keeps the door open.

   published note: [link]  revisit date: [date]

Expected output: a public note with a revisit date. Success check: the next person who asks gets a link, not a meeting.

Variant phrasings

Is MCP worth it for a small API

ROI phrasing. Steps 1 and 3 carry it: demand evidence plus honest maintenance pricing.

When should a startup build an MCP server

Timing phrasing. The worksheet from step 4, with emphasis on waiting until the API surface stabilizes.

MCP server maintenance burden

Cost phrasing. Step 3 expanded: schema churn, registry syncs, and agent-behavior questions are the real ongoing cost, not hosting.

How to say no to MCP requests politely

Communication phrasing. Step 5: a public note with criteria for revisiting turns repeated asks into a link.

Why it happens

MCP looks like a one-time build and behaves like a new support surface. Every tool you expose becomes a contract with strangers' agents, and contracts need maintenance. Small teams feel this first because there is no spare owner. The framework exists because "everyone is doing it" is not a strategy and "we are too small" is not an analysis.

Edge cases / pitfalls

• A read-only pilot is a legitimate middle answer. Exposing three stable read tools costs little and answers the demand question with data.
• Community-built servers will appear whether you build one or not. If yours does not exist, someone else's unofficial one becomes the default; decide if you are comfortable with that before saying no.
• Demand can be manufactured by one loud user. Weight independent asks from different people over a long thread from one person.
• Revisit dates matter. A no without a revisit date calcifies into a never; put the quarter on the calendar when you write the note.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3txXyuiDnhRxCPi37kQAsg