For engineers integrating tools
What is MCP (Model Context Protocol), and how to build an MCP server
MCP is a standard interface that lets any compatible client use your tools and data without bespoke glue. Instead of writing a one-off integration for every model, app, and tool combination, you expose your capabilities once over MCP and any MCP-compatible client can discover and call them.
The common analogy is "USB-C for AI tools": one standard port instead of a different cable for every device. You build an MCP server that wraps whatever you want the model to reach, and clients like Claude connect to it.
What MCP is
The Model Context Protocol (MCP) is an open protocol that standardizes how applications provide context and tools to large language models. It is maintained as a public specification (see modelcontextprotocol.io) and is implemented by a growing set of clients and servers.
Before a standard like this, every team wired its own bridge between a model and its tools: a custom adapter for the database, another for the ticketing system, another for the file store, each tied to one app. MCP collapses that into a single interface. A server advertises what it offers; a client discovers those capabilities at runtime and uses them. The integration is written once, against the protocol, rather than once per pairing.
The three primitives
MCP organizes what a server exposes into three primitives. Keeping them distinct matters because clients and models treat them differently.
Tools
Model-callable functions with typed inputs. A tool is something the model can decide to invoke - run a query, send a message, create a record - with arguments described by a JSON schema so the client knows what is valid.
Resources
Data and content the model can read. Resources are addressable pieces of context - a document, a file, a record - that a client can pull in and hand to the model, rather than actions the model takes.
Prompts
Reusable prompt templates. A server can publish parameterized prompts that clients surface to users or feed to the model, so common workflows do not have to be re-authored in every app.
| Primitive | What it is | Example |
|---|---|---|
| Tools | Model-callable functions with typed (JSON-schema) inputs the model can invoke to take an action | "create_ticket", "run_sql_query", "send_email" |
| Resources | Data and content the model can read as context, addressed by the server | A design doc, a customer record, a log file |
| Prompts | Reusable, parameterized prompt templates the server publishes for clients to use | A "summarize this incident" template with slots |
MCP vs an API
It is easy to conflate the two, but they sit at different layers. An API is the underlying service - the thing that actually does the work. MCP is a standardized interface for model-to-tool interaction on top of that, adding discovery and schemas so a model can find and call capabilities consistently across clients.
In practice an MCP server frequently wraps existing APIs and exposes them to any MCP-compatible client. You are not replacing your API; you are giving the model a uniform, self-describing way to use it. The same server then works with any client that speaks MCP, instead of being bound to one application's custom integration code.
How to build an MCP server
The shape of a server is consistent even though exact function names and types evolve - check the current spec for signatures. Conceptually, the steps are:
1. Define your tools
Decide what actions the model should be able to take, and describe each tool's inputs with a JSON schema. The schema is the contract: it tells the client what arguments are valid and lets the model fill them in correctly.
2. Implement each tool handler
Write the function that runs when a tool is called. This is usually where you call your existing API or service and return a result the model can use.
3. Expose resources and prompts as needed
Publish the readable data the model should be able to pull in, and any reusable prompt templates, using the resource and prompt primitives. Not every server needs all three - add what your use case calls for.
4. Validate all tool inputs
Apply least privilege and never trust model-supplied arguments. Validate against the schema and your own constraints before doing anything with the values. The model's output is untrusted input by definition.
5. Connect a client and test
Connect an MCP client (for example, Claude) to the server and verify both halves: discovery (does the client see your tools, resources, and prompts?) and execution (do calls run and return correctly?). See the current spec and the Anthropic platform docs for client configuration details.
Security
Tools are an attack surface. The moment a model can take an action, a bad or manipulated input can take that action too. Treat every server with the same caution you would any system that executes on behalf of an untrusted caller: least privilege on what each tool can reach, strict input validation, and human-in-the-loop confirmation on irreversible actions.
Prompt injection makes this concrete - content a model reads can try to steer the tools it calls. Scope credentials tightly, validate before acting, and require explicit approval for anything you cannot easily undo.
- Model Context Protocol specification (modelcontextprotocol.io) - the protocol, its primitives, and client/server behavior.
- Anthropic platform docs (MCP, tool use) - building servers and connecting clients such as Claude.
This is a conceptual overview; exact API shapes and function signatures evolve - check the current spec before implementing. Corrections: hello@aiarch.dev.
Build the tool-integration skills production teams actually need.
AI Architect Academy teaches tool use, agentic design, and safe integration as first-class skills - across Anthropic, AWS, and Cloudflare - so you can ship systems that use tools reliably and safely.
Get notified when new tracks ship.