Describe what a minimal MCP server must implement and how the official TypeScript and Python SDKs reduce that implementation burden.
Free · 2 AI evals / day
An **MCP server** is a small program that offers tools, data, and prompt templates to an AI host. At the protocol level it must answer three JSON-RPC methods. `initialize` is the handshake: it reports the server's name, version, and which capabilities it supports. `tools/list` returns the menu of tools, each with a name, a description, and an `inputSchema`. `tools/call` runs one tool with the given arguments and sends back the result.
Writing all of that by hand means a lot of boilerplate: parsing JSON-RPC messages, matching responses to requests, formatting errors. That is where the official SDKs save you.
The TypeScript SDK and the Python SDK let you declare a tool as a normal function with type annotations. The SDK reads those annotations, auto-builds the JSON Schema, registers the handlers, and runs all the wire plumbing.
You also pick a transport in one line. Use stdio when the host launches your server as a local subprocess. Use Streamable HTTP when the server is remote.
So the mental model is simple: declare functions, choose a transport, and the SDK turns them into a compliant server.
A minimal MCP server is a JSON-RPC endpoint that answers three methods.
First, `initialize` performs the handshake. The server returns its protocol version, name, and the capabilities it advertises. Next, `tools/list` returns the catalog. Each entry carries a name, a description, and an `inputSchema` expressed as JSON Schema. Finally, `tools/call` receives a tool name plus arguments, runs the logic, and returns a content array. Resources and prompts are optional primitives layered on the same pattern.
The official SDKs remove almost all of that burden. In the Python SDK you write a plain function and add the `@mcp.tool()` decorator. In the TypeScript SDK you call `server.registerTool` with a Zod schema. Either way the SDK generates the JSON Schema from your type hints, owns message framing, error formatting, and request-id correlation, and ships transport adapters you attach in one line.
That last point matters for deployment. Pick stdio when the host spawns your server locally. Pick Streamable HTTP for a remote server reachable over the network. Both are built in, so the same tool definitions run unchanged across either transport. The result is a few decorated functions instead of hundreds of lines of protocol code.
Quick reference
TL;DR
A minimal MCP server handles initialize, tools/list, and tools/call over JSON-RPC; the official SDKs collapse that to a few decorated functions plus a one-line transport.
Think of opening a food stall at a market. The market has a fixed rulebook: you must put up a sign listing what you sell, show prices, and hand over an order when someone pays. Writing all that paperwork by hand for every stall is tedious. The official SDK is like a stall-starter kit: you just write 'I sell coffee, it costs three dollars, here is how I make it', and the kit prints the sign, takes the orders, and counts the money for you. You declare your tools as plain functions, and the SDK builds the catalog, validates the orders, and talks to the customer (the host) in the exact format the market rulebook demands. You pick stdio for a local stall, or Streamable HTTP for a remote one, in a single line.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A single closed app that calls one vendor's tools with no plug-in story The protocol and process boundary add startup cost while buying no cross-host reuse.
An in-process tool with a latency budget under five milliseconds Even stdio JSON-RPC adds a process hop and serialisation cost a direct call avoids.
A capability that is purely read-only reference data Model it as a resource rather than a tool, so the host can pull it without a tool round-trip.
Quick scan · 2–4 min
Everything important, quickly.
5 min: the three mandatory handlers + the initialize handshake + how SDKs generate schema from types and own JSON-RPC plumbing + stdio vs Streamable HTTP + testing with the Inspector.
Code example
python
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("weather")
@mcp.tool()
def get_weather(city: str) -> str:
"""Return the current weather for a city."""
return f"Sunny in {city}, 22C"
if __name__ == "__main__":
# stdio for local; swap to transport="streamable-http" for remote
mcp.run(transport="stdio")
Side-by-side
Concern
stdio transport
Streamable HTTP transport
Where it runs
Local subprocess of the host
Remote server over the network
Lifecycle
Tied to host process
Independent, long-lived service
Auth
None needed (local trust)
OAuth 2.1 bearer tokens
Best for
Filesystem, Git, local dev tools
Shared SaaS tools, hosted integrations
Real-world examples
Real products, models, and research that use this idea.
1The Python SDK's FastMCP API lets you expose a tool with one @mcp.tool() decorator and run mcp.run(transport='stdio').
2Anthropic ships official MCP servers for filesystem, Git, and Postgres built on these same SDKs.
3The MCP Inspector tool launches a server, lists its tools, and lets you invoke tools/call interactively before host integration.
4Cursor, Zed, and Claude Code all load stdio MCP servers from a config file and call tools/list at startup.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does the SDK keep the advertised inputSchema and the runtime argument validation from drifting apart?
Sign in or go Pro to see the approach for this follow-up.
QWhy did Streamable HTTP replace the older HTTP plus SSE transport for remote servers?
Sign in or go Pro to see the approach for this follow-up.
QHow would you expose a read-only data source rather than an executable tool, and why prefer that?
Sign in or go Pro to see the approach for this follow-up.
QWhat should an error response look like when a tool fails at runtime?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Thinking you must hand-write JSON Schema and JSON-RPC framing. The SDK generates the schema from your type hints and owns all the wire plumbing.