What is MCP? The protocol plugging AI into everything
MCP - the Model Context Protocol - is the open standard that connects AI models to tools and data. Think USB-C for AI: one plug, any host, any capability. Introduced by Anthropic in late 2024 and adopted across the industry since, it’s now the default answer to “how do I give an AI access to my system?” Here’s the full picture - including a working server in 30 lines, and the security caveats the hype skips.
Rewind to before the protocol. Every AI application that wanted to dothings - read your files, query your database, post to Slack - built its own custom integrations. Every system that wanted to be AI-accessible built a different plugin for every AI app. Connect N applications to M systems and you’re maintaining N×M bespoke bridges, each with its own bugs, auth quirks, and update treadmill. It was the same wall the hardware world hit before USB: every device shipping its own cable.
MCP’s move is the standard-protocol move: N+M instead of N×M. Each AI application implements the protocol once, as a host. Each system gets one small serverthat exposes its capabilities in a standard, self-describing format. From then on, everything interoperates: the server you write for your order database works in Claude, in Cursor, in ChatGPT, in your own agent - unchanged. When OpenAI and Google joined Anthropic in backing the standard through 2025, the network effect locked in; by 2026 the ecosystem counts thousands of servers, and “does it have an MCP server?” is the new “does it have an API?”
How it works: three roles
The whole architecture fits in three boxes.
Host - the AI application
The app the user actually talks to: Claude, ChatGPT, Cursor, an IDE, your own agent. The host runs the model and decides, each turn, whether one of the connected servers has something useful to offer.
Server - the capability provider
A small program that exposes one system to AI: your database, GitHub, Slack, a filesystem, your company’s internal API. It speaks MCP on one side and the underlying system on the other. Write it once and every MCP host can use it.
The primitives - tools, resources, prompts
Servers expose three things: tools (actions the model can invoke - “create_invoice”), resources (data the host can read - files, records), and prompts (reusable task templates). Tools dominate in practice; the model sees each one’s name, description, and typed schema.
If you’ve read our guide on how agents work, MCP will feel familiar: tools with names, descriptions, and schemas are exactly the agent-tool pattern - MCP just standardises the plug so tools become shareable across every host.
The walkthrough: a real server in ~30 lines
The best way to demystify MCP is to see how little there is to it. Here’s a complete, working server exposing one business capability - order-status lookup - using the official TypeScript SDK:
order-tools.ts - a complete MCP server
// A complete MCP server in ~30 lines (TypeScript, official SDK).
// It exposes one tool: looking up an order's status from your system.
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'
const server = new McpServer({ name: 'order-tools', version: '1.0.0' })
server.registerTool(
'get_order_status',
{
description:
'Look up the current status of a customer order by its order ID.',
inputSchema: { orderId: z.string().describe('e.g. "ORD-20260824-113"') },
},
async ({ orderId }) => {
const res = await fetch(`https://api.your-shop.com/orders/${orderId}`)
const order = await res.json()
return {
content: [
{
type: 'text',
text: `Order ${orderId}: ${order.status}, ETA ${order.eta}`,
},
],
}
},
)
// stdio transport: the host (Claude, Cursor, ...) launches this process
// and speaks MCP over stdin/stdout. Remote servers use HTTP instead.
await server.connect(new StdioServerTransport())
// That's it. Register this server in any MCP host's config, and every
// AI app you use can now check order statuses - same code, every host.
Three things worth noticing. The description is the interface - the model reads it at runtime to decide when and how to call your tool, so writing it clearly is prompt engineering, not documentation. The schema is the contract - typed inputs (via Zod here) mean the host validates calls before your code runs. And the server is trivially smallbecause it’s a translation layer: MCP on one side, your existing API on the other. That’s the general pattern - most of the thousands of servers in the ecosystem are exactly this shape, wrapped around GitHub, Postgres, Slack, browsers, filesystems, and every SaaS you’ve heard of.
For a working developer, the career translation is direct: the systems you already know - your company’s internal tools, your industry’s software - become AI-accessible the moment someone writes the server. Being the person who can write it is exactly the kind of leverage we mean when we talk about the domain + code combination.
The caveats every MCP guide should carry
A standard plug means anything can be plugged in - including things that shouldn’t be. Three risks deserve adult respect. Untrusted servers:a community MCP server is code running with whatever access you grant it; vet before installing, prefer official servers, and treat a random server with database credentials the way you’d treat a random npm package with production keys. Tool poisoning:tool descriptions and results flow into the model’s context, so a malicious server can embed instructions that steer the model - the MCP-era flavour of prompt injection. Over-broad access: a server with write access to production is one confused tool-call away from a very bad afternoon; least-privilege credentials, read-only modes, and confirmation gates on destructive actions are the standard hygiene. None of this argues against MCP - it argues for connecting deliberately, which is true of every powerful plug ever invented.
FAQ
What is MCP (Model Context Protocol)?
MCP is an open standard - introduced by Anthropic in November 2024 - for connecting AI models to external tools and data sources. It defines a common language between AI applications (hosts like Claude, ChatGPT, or Cursor) and lightweight programs (servers) that expose capabilities: query a database, read files, call an internal API. The standard analogy is USB-C for AI: instead of every AI app building custom integrations with every system, both sides implement one protocol, and any host can use any server.
What problem does MCP actually solve?
The N×M integration explosion. Before MCP, connecting N AI applications to M systems meant building and maintaining N×M custom integrations - every chatbot needed its own GitHub plugin, its own database connector, its own Slack bridge. MCP collapses that to N+M: each AI app implements the protocol once, each system gets one server, and everything interoperates. That’s why adoption snowballed - after OpenAI and Google joined Anthropic in supporting it through 2025, building an MCP server became the default way to make any system AI-accessible.
What is the difference between MCP and an API?
An API is how software talks to your system; MCP is how AI models talk to it. The practical difference is the audience: an API assumes a programmer will read the docs and write correct calls, while an MCP server describes its capabilities in a machine-readable way (names, descriptions, typed schemas) that a model reads at runtime to decide what to call and how. Most MCP servers are thin wrappers over existing APIs - the value added is the standardised, self-describing layer that any AI host can discover and use without custom code.
Do I need to know MCP to build with AI?
If you’re building agents or AI features in 2026 - yes, at least the basics, because it’s become the standard way to give models capabilities, the way REST became the standard for web APIs. The good news: the learning curve is shallow. A working server is ~30 lines with the official SDKs, and conceptually it’s just "tools with a standard plug". If you’re still learning to code, MCP is not step one - fundamentals and the agent loop come first; MCP is how you’ll share and consume tools once you’re building.
Is MCP safe to use?
The protocol is sound; the risks live in what you connect. Three deserve respect: untrusted servers (a community MCP server runs with whatever access you grant - vet before installing, prefer official ones), tool poisoning (a malicious server’s tool descriptions or results can carry hidden instructions that steer the model), and over-broad access (a server with write access to production is one confused model-call from a bad day). Sensible defaults: least-privilege credentials, read-only where possible, and confirmation gates on destructive actions.
Learn to build the things AI plugs into. Fundamentals first, protocols follow.
MCP takes an afternoon once you can build software. The 12-week AI-Native Software Development Programme gets you there from zero - shipping real, AI-connected products under mentor review. Try it free first, no card.
