What Is the Model Context Protocol (MCP)?
Abhay
4 min read
Picture this: you’ve built a slick AI assistant. Now you want it to read your Google Drive, query your Postgres database, file tickets in Jira, and check the weather. So you write four integrations. Then a coworker builds a different assistant and writes the same four integrations from scratch. Multiply that across every AI app and every tool on earth and you get the dreaded M×N problem — M models times N tools, each pairing a bespoke lump of glue code that someone has to write, test, and maintain forever.
The Model Context Protocol (MCP) exists to turn that ugly multiplication into a tidy addition. Build one MCP server for your tool, and every MCP-aware AI app can use it. Build one MCP client into your app, and it can reach every MCP server. M+N, not M×N.
USB-C, but for AI tools
The analogy everyone reaches for — including MCP’s own creators at Anthropic — is “a USB-C port for AI applications.” Before USB-C, every device had its own weird connector and you owned a drawer full of cables you were afraid to throw away. MCP is the standard plug: a single, open protocol for connecting language models to data and tools.
And “open” is doing real work here. MCP launched in late 2024, and within months it stopped being an Anthropic thing and became an everyone thing. OpenAI adopted it across its products in March 2025 (Sam Altman said so out loud). Google DeepMind confirmed Gemini support shortly after. Microsoft Copilot joined the party. By late 2025 the protocol was governed openly, with thousands of public servers in the registry and SDKs for TypeScript, Python, C#, Java, and Swift. When your competitors all agree to use your plug shape, you’ve won the standards war.
The core concepts
MCP has three roles. A host is the AI app you actually use (Claude Desktop, an IDE, ChatGPT). Inside the host, a client maintains a one-to-one connection to a server, which is the little program that exposes a capability — your filesystem, your database, GitHub, whatever.
Servers offer three flavours of “context,” and the distinction is worth knowing:
- Tools — executable actions the model can call.
send_email,run_query,create_issue. These do things and may have side effects. - Resources — read-only data the model can pull in. A file, a database row, an API response. Think GET, not POST.
- Prompts — reusable templates the user or app can invoke, like a saved “summarize this PR” workflow.
A tool definition is just JSON describing a name, a description, and a schema for its inputs:
{
"name": "get_weather",
"description": "Get the current weather for a city",
"inputSchema": {
"type": "object",
"properties": {
"city": { "type": "string" }
},
"required": ["city"]
}
}
The model reads that description, decides it wants the weather in Lisbon, and the client calls the tool. No custom parsing, no fragile prompt-stuffing — just a standard request and response.
Why agents care
For a chatbot, MCP is a convenience. For an agent — an AI that plans and acts over many steps — it’s closer to oxygen. An agent is only as capable as the actions available to it, and MCP gives it a uniform, discoverable menu of actions it can browse at runtime. Add a new server and the agent can suddenly do new things without anyone retraining or redeploying it.
The protocol keeps evolving in exactly this direction. The 2026 spec made MCP stateless at its core so it scales on ordinary HTTP infrastructure, added a Tasks extension for long-running work (so an agent can kick off a job and check back later), and introduced MCP Apps for servers that ship interactive UIs into the host. Authorization got friendlier too, aligning with OAuth and OpenID Connect so enterprises can actually approve the thing.
How you’d actually connect one
Here’s the genuinely fun part: using an existing server is usually a config file, not a coding project. Many hosts let you register a server by pointing at a command to run:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/notes"]
}
}
}
Restart the host, and your assistant can now read those notes. Want to build your own? Install an SDK and you’re off:
pip install mcp
…then define a tool, describe it, and let the protocol handle the plumbing.
The takeaway
MCP is the boring-but-load-bearing infrastructure that lets AI stop being a clever text box and start doing things across your real tools — without every team reinventing the same connectors. Your move: pick one repetitive thing you wish your AI could touch (your notes, your calendar, your codebase), find or write a small MCP server for it, and wire it into a host you already use. Once you’ve plugged in one tool, the whole M+N world clicks into focus — and you’ll never want to hand-roll another integration again.