Every team that builds with language models hits the same wall. The model is capable, but it can't see your ticketing system, query your database, or read your internal docs. So someone writes a custom integration. Then another team writes a different one for a different assistant. Within a year there are a dozen bespoke connectors, each with its own auth quirks and none reusable.
The Model Context Protocol, or MCP, is an attempt to fix that with a shared standard. Think of it as a common plug shape between AI applications and the things they need to reach.
What MCP is
MCP is an open protocol, introduced by Anthropic in late 2024 and since adopted well beyond a single vendor, that standardizes how AI applications discover and use external capabilities. Messages are exchanged using JSON-RPC, so the shape of a request and response is predictable regardless of who built each side.
The core idea is separation of roles:
- Host: the AI application the user interacts with — a chat assistant, a coding tool, an agent framework.
- Client: a component inside the host that maintains a connection to one server.
- Server: a small program that exposes specific capabilities from a system — a database, a SaaS API, a file store.
Build an MCP server once for your internal ticketing system, and any MCP-capable host can use it without a bespoke integration.
What a server can offer
Servers expose three main kinds of capability:
| Primitive | What it is | Example |
|---|---|---|
| Tools | Actions the model can call | create_ticket, run_query |
| Resources | Data the application can read | A file, a database record, a document |
| Prompts | Reusable prompt templates | "Summarize this incident" |
Tools are the most commonly used, and they map closely to the function-calling pattern covered in our post on function calling and structured outputs. The difference is that MCP standardizes how tools are discovered and described across applications, rather than defining them inline in each app.
How it connects
MCP supports two main transports. Standard input/output (stdio) runs the server as a local subprocess — simple and common for developer tools. HTTP-based transport lets a server run remotely and serve multiple clients, which is how hosted and shared servers are typically delivered, with authorization handled through OAuth-based flows in the specification.
A minimal server
Using the official Python SDK, a working server is a few lines:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("order-status")
@mcp.tool()
def get_order_status(order_id: str) -> str:
"""Look up the shipping status of an order by its ID."""
# In real life: call your order system here
return f"Order {order_id}: shipped, arriving Thursday"
if __name__ == "__main__":
mcp.run() # defaults to the stdio transportThe function's name, type hints, and docstring become the tool's description — which matters, because that description is what the model reads to decide when to use it. Then register the server with a host. For example, in a desktop assistant's configuration file:
{
"mcpServers": {
"order-status": {
"command": "python",
"args": ["server.py"]
}
}
}The exact configuration location varies by host, so check your tool's documentation.
Why teams care
- Write once, reuse everywhere. One server serves many assistants and agents.
- Cleaner separation of concerns. The team that owns a system also owns its MCP server, with its own access rules.
- A growing ecosystem. Ready-made servers exist for many common services, which is faster than building from scratch — though see the next section before installing anything.
The security questions to ask first
An MCP server gives a model real capabilities, which means real risk. Before connecting one, ask:
- Who wrote it, and can we review it? A server runs code and may handle credentials. Treat third-party servers like any dependency you'd vet.
- What's the minimum access it needs? Scope credentials narrowly. A read-only ticket viewer shouldn't hold write access to everything.
- What happens when tool output contains instructions? Text returned from tools or documents can include malicious instructions aimed at the model — prompt injection. Don't give a single agent both untrusted input and powerful actions without guardrails.
- Which actions need a human in the loop? Require approval for anything destructive, financial, or externally visible. Our post on human-in-the-loop workflows with LangGraph shows the pattern.
- Is it logged? You want an audit trail of which tool was called, with what arguments, by whom.
None of this is hypothetical. Our write-ups of the LiteLLM breach and of AI agents that breached real companies show how credentials and tool access around AI systems become the attack surface.
Where MCP fits in your stack
MCP doesn't replace your agent framework or your model; it standardizes the connection layer beneath them. If you're building agents, it pairs naturally with the orchestration ideas in LangChain agents and tools explained.
Learn it hands-on
The fastest way to understand MCP is to build a server against a real system and watch a model use it. Our AI Agents: Concepts and Practical Design course covers agent design and tool use hands-on, and like all our programs it can be adapted to the tools and systems your team actually works with. Building with Claude: A Developer's Guide is the natural starting point for developers new to building on a model API. If you're planning to connect agents to internal systems, talk to us about a workshop built around your own use case.