Here’s the thing nobody tells you about AI assistants: they’re brilliant inside their own heads, but historically terrible at reaching outside them. Claude can reason through your architecture decisions, write production-grade code, and debate the finer points of distributed systems design. But ask it to check your Jira board, query your database, or pull the latest metrics from Datadog? That used to be a hard stop.
Not anymore. The Model Context Protocol changed the game. And if you’re not paying attention to MCP connectors, you’re leaving an absurd amount of capability on the table.
Let’s break down what MCP actually is, how it works under the hood, how to build your own connectors, and why this open standard might be the most consequential thing to happen in the AI tooling space since function calling. This is the real stuff, no hand-waving.
What Is the Model Context Protocol?
MCP is an open standard for connecting AI models to external tools, data sources, and services. Anthropic released it in late 2024, and by early 2026 it’s become the dominant protocol for AI-tool integration, adopted not just by Claude but by a growing list of AI providers and developer platforms.
Think of it this way. Before USB, every peripheral had its own proprietary connector. Printers needed one cable, keyboards needed another, scanners needed a third. It was a mess. Then USB showed up and said: one standard, any device, any computer. Plug it in and it works.
MCP is USB for AI tools. It’s a universal standard that lets any tool connect to any AI. Build an MCP server today and your tool works with Claude. Tomorrow, it works with every other MCP-compatible AI. That’s the hidden layer here, and it’s massive.
The protocol defines a clean contract between AI applications and the services they need to interact with. Instead of building bespoke integrations for every tool-model combination, you build one MCP server and every MCP-compatible client can use it. The combinatorial explosion of N models times M tools collapses into N plus M. If you’ve built API integrations before, you know why that matters.
MCP Architecture: The Three-Layer Stack
MCP follows a client-server architecture, but there are three distinct components you need to understand. Get these wrong and everything downstream gets confusing.
MCP Hosts
The host is the AI application itself. Claude Desktop, Claude Code, an IDE with AI capabilities, your custom chatbot built on the Anthropic API. The host is where the LLM lives, where conversations happen, and where MCP connections get orchestrated.
The host maintains the LLM instances, spawns MCP clients, manages the lifecycle of connections, and decides which tools to surface to the model. If you’re building an AI-powered application, your application is the host.
MCP Clients
Each host spawns one or more lightweight MCP clients. Here’s the critical detail: each client maintains a dedicated, one-to-one connection with a single MCP server. One client, one server. No multiplexing, no shared connections.
The client handles protocol-level messaging. It discovers what capabilities the server offers at runtime, manages the connection lifecycle, and translates between the host’s internal representation and the MCP wire format. Think of clients as dedicated ambassadors, each one managing the relationship with a single external service.
MCP Servers
This is where the actual capabilities live. An MCP server is a backend program that wraps a specific data source or tool in the MCP protocol. It translates the unique API of whatever service it represents, a database, a SaaS platform, a local file system, into the common language of MCP.
Servers expose three types of primitives to clients:
Tools are callable functions. The AI model can invoke them, pass parameters, and get results back. Think “execute a database query,” “create a GitHub issue,” or “send a Slack message.” Tools are model-controlled, meaning the AI decides when and how to call them based on the conversation context.
Resources are injectable context data. These are read-only data sources that provide information to the model. A resource might expose your project’s README, a configuration file, or the current state of a database table. Resources are application-controlled, meaning the host decides what resources to surface.
Prompts are parameterized templates. These are reusable prompt structures that servers can offer, like a code review template or a data analysis workflow. Prompts are user-controlled, typically selected explicitly by the human operator.
This three-primitive model is elegant because it separates concerns cleanly. Tools do things. Resources provide context. Prompts structure interactions. Each has a different control model (AI, application, user), which prevents the kind of chaotic tool sprawl that plagues less thoughtful integration approaches.
Under the Hood: How MCP Actually Communicates
MCP uses JSON-RPC 2.0 as its wire format. If you’ve worked with Language Server Protocol (LSP) for IDE integrations, this will feel familiar. Every message is a JSON-RPC request, response, or notification.
The protocol supports two official transport mechanisms:
stdio is for local servers. The host spawns the server as a subprocess and communicates over standard input/output. This is dead simple, requires zero network configuration, and is perfect for development tools, local file access, and anything that runs on the same machine as the host.
Streamable HTTP is for remote servers. The client sends HTTP POST requests to the server and can receive Server-Sent Events (SSE) for streaming responses. This is what you use for cloud-hosted services, SaaS integrations, and anything that needs to be accessed over the network. The older SSE-based transport is deprecated but you’ll still see it in legacy implementations.
The transport layer is fully abstracted from the protocol layer. The same JSON-RPC messages flow regardless of whether you’re talking over stdio or HTTP. This means you can develop locally with stdio and deploy remotely with Streamable HTTP without changing your server logic.
Authentication for remote servers uses OAuth 2.1 with PKCE, which was formalized in the June 2025 spec revision. This is enterprise-grade security, not toy API keys. If you’re building connectors for production use, this matters.
The Discovery Mechanism: Self-Documenting Tools
Here’s where MCP gets genuinely clever. When a client connects to a server, the first thing it does is discover what the server offers. The server responds with a complete inventory of its tools, resources, and prompts, including descriptions, parameter schemas, and return types.
This self-documenting approach means Claude doesn’t need hard-coded knowledge of your tools. It reads the tool definitions at connection time, understands what each tool does based on its description and schema, and can reason about when to use each one. Add a new tool to your server, restart the connection, and Claude immediately knows about it.
The tool schema follows JSON Schema, so parameter validation is built into the protocol. The AI model knows not just that a tool exists, but exactly what inputs it expects and what outputs it returns. This dramatically reduces hallucinated tool calls and parameter mismatches.
Building Your First MCP Server: Python with FastMCP
Enough theory. Let’s build something. The fastest way to create an MCP server is with FastMCP, the Pythonic framework that handles all the protocol plumbing so you can focus on your tool logic.
Here’s a complete, working MCP server that exposes a weather lookup tool and a system status resource:
from fastmcp import FastMCP
from datetime import datetime
# Create the server
mcp = FastMCP(
"WeatherOps",
description="Weather data and system status tools"
)
@mcp.tool()
def get_weather(city: str, units: str = "celsius") -> dict:
"""Get current weather for a city.
Args:
city: City name (e.g., 'London', 'Tokyo', 'New York')
units: Temperature units - 'celsius' or 'fahrenheit'
"""
# In production, call a real weather API here
response = httpx.get(
"https://api.weatherservice.example/current",
params={"q": city, "units": units}
)
data = response.json()
return {
"city": city,
"temperature": data["temp"],
"units": units,
"conditions": data["conditions"],
"humidity": data["humidity"],
"retrieved_at": datetime.now().isoformat()
}
@mcp.tool()
def get_forecast(city: str, days: int = 5) -> list:
"""Get multi-day weather forecast.
Args:
city: City name
days: Number of forecast days (1-14)
"""
if days < 1 or days > 14:
raise ValueError("Days must be between 1 and 14")
response = httpx.get(
"https://api.weatherservice.example/forecast",
params={"q": city, "days": days}
)
return response.json()["forecast"]
@mcp.resource("system://status")
def system_status() -> dict:
"""Current system operational status."""
return {
"status": "operational",
"uptime_hours": 472,
"last_data_refresh": datetime.now().isoformat(),
"api_version": "2.1.0"
}
if __name__ == "__main__":
mcp.run()
That’s it. No boilerplate protocol handling, no JSON-RPC serialization code, no transport configuration. FastMCP infers the tool schemas from your type hints, generates descriptions from your docstrings, and handles all the MCP protocol negotiation automatically.
Notice how the @mcp.tool() decorator turns a plain Python function into a discoverable, schema-validated MCP tool. The type hints on city: str and units: str = "celsius" become the JSON Schema that Claude uses to understand what parameters the tool accepts. The docstring becomes the tool description that Claude reads to understand when to invoke it.
The @mcp.resource() decorator works similarly but exposes read-only data. Resources are identified by URI-like strings, and the AI can reference them for context without explicitly calling them as tools.
Building an MCP Server in TypeScript
If TypeScript is more your speed, here’s the equivalent using the official MCP SDK:
const server = new McpServer({
name: "DevOps Tools",
version: "1.0.0",
description: "Development and operations utilities",
});
// Define a tool with Zod schema validation
server.tool(
"query_logs",
"Search application logs by service, level, and time range",
{
service: z
.string()
.describe("Service name (e.g., 'api', 'worker', 'gateway')"),
level: z.enum(["debug", "info", "warn", "error"]).default("error"),
hours: z
.number()
.min(1)
.max(720)
.default(24)
.describe("How many hours back to search"),
query: z
.string()
.optional()
.describe("Optional text search within log messages"),
},
async ({ service, level, hours, query }) => {
// Your actual log querying logic here
const logs = await queryLogStore(service, level, hours, query);
return {
content: [
{
type: "text",
text: JSON.stringify(logs, null, 2),
},
],
};
},
);
server.tool(
"deploy_status",
"Check the deployment status of a service",
{
service: z.string().describe("Service name to check"),
environment: z.enum(["staging", "production"]).default("production"),
},
async ({ service, environment }) => {
const status = await getDeploymentStatus(service, environment);
return {
content: [
{
type: "text",
text: `${service} (${environment}): ${status.version} - ${status.state}`,
},
],
};
},
);
// Connect via stdio transport
const transport = new StdioServerTransport();
await server.connect(transport);
The TypeScript SDK uses Zod v4 for schema validation instead of type hints, but the mental model is identical. Define your tools with schemas and handlers, connect a transport, and the SDK handles everything else.
Both examples produce servers that Claude (or any MCP client) can connect to and immediately start using. The AI reads the tool names, descriptions, and parameter schemas, then autonomously decides when each tool is relevant during a conversation.
Connecting MCP Servers to Claude
Once you’ve built a server, connecting it to Claude is straightforward. For Claude Desktop, you add your server to the configuration file:
{
"mcpServers": {
"weather-ops": {
"command": "python",
"args": ["-m", "weather_ops_server"],
"env": {
"WEATHER_API_KEY": "your-key-here"
}
},
"devops-tools": {
"command": "npx",
"args": ["-y", "devops-tools-mcp"]
}
}
}
For Claude Code, you can add servers via the CLI with claude mcp add or edit the settings JSON directly. Remote servers use a URL instead of a command, and the client handles OAuth authentication automatically.
The key insight here is that once connected, these tools become native capabilities of Claude within that session. Claude doesn’t just call your tools mechanically. It reasons about when to use them, chains them together, and incorporates the results into its thinking. Ask Claude to “check if the API is healthy and look at the last hour of error logs” and it will invoke both deploy_status and query_logs without you specifying which tools to use.
The Community Ecosystem: What’s Already Built
You don’t have to build everything from scratch. The MCP ecosystem has exploded. As of early 2026, there are over 1,800 community-built MCP servers covering virtually every category you can think of.
The big categories where community servers shine:
Developer Tools: GitHub, GitLab, Jira, Linear, Sentry, PagerDuty. If your engineering team uses it, there’s probably an MCP server for it. The official GitHub MCP server alone lets Claude create issues, review pull requests, search code, and manage repositories.
Data and Databases: PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch. Connect Claude directly to your data layer. Query databases, inspect schemas, analyze data patterns, all through natural language.
Cloud and Infrastructure: AWS, GCP, Azure, Docker, Kubernetes. Manage infrastructure, check resource status, and troubleshoot deployments without leaving your conversation with Claude.
Browser Automation: Playwright-based servers that let Claude interact with web pages, fill forms, extract data, and automate browser workflows. This is consistently one of the most popular categories by usage metrics.
Communication: Slack, Discord, email platforms. Let Claude draft and send messages, search conversation history, or monitor channels for specific topics.
Knowledge and Search: Web search, Wikipedia, ArXiv, documentation sites. Give Claude access to current information beyond its training data.
Discovery platforms like mcp.so and the awesome-mcp-servers GitHub repository serve as directories where you can browse, evaluate, and install community servers. Seven of the top ten most-used servers are official implementations maintained by the tool creators themselves, which tells you something about the maturity of the ecosystem.
Production Considerations: What the Tutorials Skip
Building a demo MCP server is easy. Running one in production is a different conversation. Here’s what you actually need to think about.
Error handling matters enormously. When your MCP tool fails, the AI model needs to understand what went wrong and why. Return structured error messages, not stack traces. Include enough context for Claude to decide whether to retry, try a different approach, or ask the user for help.
Rate limiting and timeouts are your friends. An AI model can fire off tool calls much faster than a human clicking buttons. If your MCP server wraps an external API, implement rate limiting on the server side. Set reasonable timeouts. An LLM waiting sixty seconds for a response is sixty seconds of wasted context and user patience.
Authentication and secrets need real infrastructure. Don’t hardcode API keys in your server code. Use environment variables at minimum, and a proper secrets manager for production. The OAuth 2.1 support in MCP’s Streamable HTTP transport gives you enterprise-grade auth for remote servers, so use it.
Idempotency matters for tool calls. AI models sometimes retry tool calls, especially in agentic workflows. If your tool creates a database record or sends an email, make sure duplicate calls don’t produce duplicate side effects. This is standard API design discipline, but it’s easy to forget when you’re focused on the MCP integration layer.
Logging and observability aren’t optional. You need to know what tools Claude is calling, how often, with what parameters, and what results it’s getting. This isn’t just debugging, it’s understanding how the AI is using your tools so you can improve descriptions, add guardrails, and optimize performance.
The Future of MCP: Where the Standard Is Heading
The MCP specification is actively evolving, with a major release tentatively planned for June 2026. Several Spec Enhancement Proposals (SEPs) are in flight that will meaningfully expand what’s possible.
Elicitation is one of the most interesting upcoming features. It lets MCP servers request human input mid-execution. Imagine a deployment tool that pauses and asks “This will affect 12 production services. Confirm?” before proceeding. The server sends an elicitation request, the client surfaces it to the user, and the response flows back through the protocol. This makes MCP servers capable of participating in interactive, human-in-the-loop workflows rather than just fire-and-forget tool calls.
Structured content is already available in recent spec revisions. Tools can now return rich, typed data instead of just text strings. This means better rendering in UIs and more precise data handling by the AI model.
Streaming improvements are being designed to support stateful agentic applications while keeping the protocol itself stateless. The vision is that applications can maintain complex multi-step workflows without the transport layer needing to track session state.
Namespace and registry standardization will make it easier to discover, trust, and version MCP servers as the ecosystem scales from hundreds to thousands of available connectors.
The trajectory is clear. MCP is moving from a protocol that connects tools to AI, toward a full platform for building AI-native applications. The servers being built today, including the one you might build after reading this article, are the foundation of that platform.
Why This Matters More Than You Think
Let me leave you with the bigger picture. Every previous generation of software integration followed the same pattern: proprietary at first, then standardized, then explosive growth. REST APIs standardized web service communication and unlocked the API economy. GraphQL standardized data querying and unlocked frontend flexibility. Webhooks standardized event notifications and unlocked real-time integration.
MCP is doing the same thing for AI-tool integration. And we’re still in the early chapters. The fact that you can build one MCP server today and have it work with Claude, with other AI platforms adopting the standard, and with every future MCP-compatible system, that’s not an incremental improvement. That’s a phase change.
The developers building MCP servers right now are the ones who built REST APIs in 2008, GraphQL resolvers in 2016, and serverless functions in 2018. They understood that standardized interfaces compound in value. Every new client that supports MCP makes every existing server more valuable. Every new server makes every existing client more capable. That’s the network effect, and it’s already running.
If you’ve been on the fence about MCP, get off it. Pick a tool your team uses every day, build an MCP server for it, connect it to Claude, and watch what happens when your AI assistant can actually do things instead of just talking about them. The protocol is stable, the SDKs are mature, the community is thriving, and the best time to start building was six months ago. The second best time is right now.