Build an MCP Server in 10 Minutes: Let AI Call Your Code Directly

Why MCP Is Worth an Afternoon of Your Time

Imagine asking a chat assistant to check your calendar — and it actually does it. Real code runs, a real answer comes back. What makes this possible is an open standard called MCP (Model Context Protocol).

Anthropic officially open-sourced MCP in November 2024. Before that, integrating AI with external tools relied entirely on proprietary implementations — OpenAI's Function Calling, LangChain's Tools system, various agent frameworks — each incompatible with the others. This fragmentation mirrored the early USB era: PS/2, serial, parallel ports all coexisting, each device requiring its own dedicated connector. In a single phrase, MCP is the USB-C of AI: one standard port that any tool can plug into any model.

Previously, every AI application had to manually build integrations for every tool. Ten apps with ten tools meant 100 fragile connectors. MCP turns that multiplication into addition — build your server once, and any client that supports the protocol can use it.

The most exciting part: you can build your own MCP server. Not next year — this afternoon. It's not a framework or service you need to rent. With roughly 20 lines of Python, AI can call your code directly.

Three Parts, Five Core Concepts

Host, Client, Server

Every MCP setup has exactly three parts: a host, a client running inside it, and the server you build. The client and your server communicate via JSON-RPC.

Don't let the acronym intimidate you. JSON-RPC is a lightweight remote procedure call protocol born in 1999. Its spec is only a few pages long, and it's still active in critical infrastructure like Ethereum node APIs. The core is minimal: every message is a JSON object with three fields — method (the function name), params (the arguments), and id (for matching responses). One side sends a request saying "call this function with these params"; the other returns a result or a clean error. Compared to REST, which requires designing URL structures and HTTP verb semantics, JSON-RPC is naturally suited to the pattern of "call a function and wait for the result." Predictable, boring, and easy to debug — exactly what you want in an AI's plumbing.

A real message on the wire might look like: method: tools/call, name: getWeather, params: {city: Tokyo}. Your server runs the matching function and returns the weather forecast in the same format. Text in, text out, no magic — you can read every line.

This idea isn't new. Code editors solved the same problem years ago with the Language Server Protocol (LSP) — introduced by Microsoft in 2016 alongside VS Code, it broke the M×N integration problem between editors and language toolchains into "editors implement clients, language teams implement servers," with both sides following the same protocol. Today, language servers like the TypeScript server and rust-analyzer are shared across dozens of editors. MCP applies the same trick to AI: swap "editor" for "AI model" and "language tools" for "external capabilities."

Tools, Resources, Prompts

MCP servers expose three things. This is the core of the entire mental model:

• Tools are the stars. They're functions the model can actually run: search a database, send an email, book a table. You describe them once in code with a name and a short explanation, and the model decides when to call them. It picks the tool; your code does the real work behind the scenes.
• Resources are read-only data. A file, a config, a row from a database. Each resource has its own address, like a small URL. The model doesn't execute resources — it just reads them, like consulting documentation before answering a hard question. Data flows in; no side effects.
• Prompts are reusable templates that users actively choose. Think of a saved workflow: "Review this PR with the same level of care" or "Draft release notes in our company style." The server provides the template, you trigger it from a menu, and the model fills in the blanks.

The channel is bidirectional: your server can also request things from the client — asking the model to handle subtasks, or posing questions to the user mid-run.

A Working MCP Server in 20 Lines of Code

One command installs the SDK. We'll use FastMCP, a Python library heavily inspired by FastAPI's design philosophy. It uses decorators and type hints to auto-generate interface specs, handling all protocol details so you can focus on the tools themselves rather than transport formats.

Writing an MCP tool is straightforward: write a normal Python function (say, for addition) with nothing special about it, then add the @mcp.tool decorator. That one line registers your function as a callable tool — it runs when the function is first imported, reads the type annotations in the function signature (like int, str, Optional[str]), converts them into JSON Schema-compliant parameter descriptions, and registers the function body in the routing table. There really is no step two.

The best part: your type hints and docstrings automatically become the tool schema. The model reads this schema to understand the tool's name, parameters, and purpose — and knows when to use it. You don't write any JSON Schema by hand. Python's native type system becomes the data source for your API documentation. Write a normal comment, and you get a typed, documented API for free.

The last two lines start everything: call mcp.run() and your server begins listening on stdin, waiting for a model to connect and call in.

Adding resources or prompts works the same way — one function, a different decorator. The entire API is remarkably consistent: learn to write one tool, and you've already internalized the pattern for all three primitives through muscle memory.

Before connecting any client, test with the MCP Inspector. It's a built-in tool that connects to your server, lists every tool you've exposed, and lets you call them manually and observe the responses. If it works here, it'll work the same way in a real client.

Local vs. Remote: Two Transport Methods

How do clients and servers actually connect? MCP provides two standard transport methods:

• STDIO: for local servers running on your own machine. The client launches your script as a subprocess, writes JSON-RPC requests to its stdin via a pipe, and reads responses from stdout. No network stack, no port listening, naturally process-isolated — a crashed subprocess doesn't affect the host. No network, no ports, no configuration. Perfect for tools that read local files or operate on local databases.
• Streamable HTTP: for remote servers that others access over the network. Early MCP specs used SSE (Server-Sent Events) as the remote transport, but SSE is inherently one-directional, architecturally awkward, and operationally painful in production deployments. The newer spec's Streamable HTTP unifies requests and responses on a standard HTTP connection, supports bidirectional streaming, and maintains compatibility with existing CDNs and load balancers. It's suited for servers deployed in the cloud with real addresses and authentication in front.

To connect your server to Claude Desktop, add a few lines pointing to your script in a JSON config file, restart the app, and your new tool appears in the model's menu. Then you just ask a normal question — the model spots your tool in the menu, decides it needs it, calls it with the right parameters, and presents the answer in natural language. The loop closes, and it feels like magic — until you remember you wrote every step yourself.

Write once, run everywhere. The same server, not a single line changed, works in Claude, ChatGPT, Cursor, and Copilot. Integrate once, and you're connected to every client that supports the protocol.

MCP Is Becoming the Industry's Shared Standard

This is no longer hopeful speculation — it's already happening.

OpenAI adopted MCP, first integrating it into their Agents SDK and later into ChatGPT itself — Anthropic's biggest competitor voluntarily adopted Anthropic's own protocol. Google's Gemini followed, then Microsoft Copilot, GitHub, VS Code, and Cursor, one after another.

A protocol from a single company became a shared standard that even its fiercest competitors agreed to use — within just one year of launch.

The numbers are also striking: there are now over 1,000 public MCP servers, the official registry lists close to 1,000, and community repositories on GitHub number over 1,500. The Python and TypeScript SDKs see roughly 97 million downloads per month — that's the growth curve of real infrastructure that teams depend on daily, not a weekend hype cycle. Anthropic has also transferred governance of the protocol to the Linux Foundation — moving control from a single commercial company to a neutral, multi-stakeholder committee, just as Kubernetes, Node.js, GraphQL, and other important projects have done. This ensures no single company controls its direction; even if Anthropic's strategy shifts, MCP can't be unilaterally modified or abandoned.

Security Risks You Must Understand Before Going Live

One serious warning: tools are arbitrary code execution. When the model calls one, your function actually runs with whatever permissions you've granted it. Prompt injection is a real threat — attackers embed text disguised as instructions in external content the model processes (web pages, documents, email bodies) to trick the model into taking unintended actions. This "indirect prompt injection" is especially insidious: the attack vector hides in resource content rather than direct user input, rendering traditional input filtering useless. If the model also has an email-sending tool, a document containing malicious instructions could directly cause a data breach. Sloppy tool permission scoping is essentially leaving the front door ajar.

This is exactly why the spec is so strict about "consent" — the host must ask the user for confirmation before running any tool, enforcing a mandatory human-in-the-loop. In industry surveys, security is consistently the biggest factor preventing teams from pushing MCP to production.

So: start with read-only tools, and add an approval step for any write operations. The spec itself continues to evolve, adding features for long-running tasks and OAuth for authentication, with further updates under review. Pin a version number in your project and read the changelog carefully before upgrading any production environment.

Closing: Open an Empty File Tonight

The whole framework is actually simple: one host, one client, one server; three primitives — tools, resources, prompts; two transports — STDIO and HTTP. Master these five concepts and you can open almost any MCP server on the internet and immediately understand what it does.

The fastest way to truly understand it is to build one yourself. Open an empty file tonight, write a tool, connect it to Claude. That small file is a real server, running on a real protocol, used by real products. Go build something with it.

Key Takeaways