MCP - The Model Context Protocol

Here's a small confession that makes a big point: the article you're reading was suggested by an AI that queried our production database directly. It didn't have database credentials baked in. It didn't have custom code written for our schema. It spoke to our database through a small program we wrote once — a program that follows an open standard called MCP, the Model Context Protocol. Any MCP-aware AI could use it tomorrow with zero changes. That is the whole promise of MCP: stop writing a bespoke integration for every combination of every AI and every tool, and start plugging them together through one universal port. If you remember when every device needed its own charger and then USB-C made one cable work for everything — that's the shift MCP brings to AI.

The Problem MCP Solves

A large language model on its own is a brilliant, well-read colleague locked in a room with no phone, no internet, and no access to your files. It can reason beautifully about what it already knows, but it can't check your calendar, read your database, search your codebase, or file a ticket. To be useful, it has to reach out into the world — and reaching out means integrations.

Before MCP, every integration was hand-built. If you wanted Claude to read from GitHub, someone wrote Claude-to-GitHub glue. If you wanted ChatGPT to read from GitHub, someone wrote different glue. Ten AI applications times ten data sources is a hundred separate integrations, each maintained forever. This is the famous M×N problem: the work grows as the product of the two sides, and it never stops growing.

MCP turns that M×N explosion into a tidy M+N. Each AI application learns to speak MCP once. Each tool or data source exposes itself via MCP once. Now any client works with any server, automatically. Ten AIs plus ten sources is twenty pieces of work, not a hundred — and every new tool you add instantly works with every AI that already speaks the protocol.

A Brief History

MCP was introduced and open-sourced by Anthropic in late 2024. Crucially, they didn't keep it proprietary — they published the specification, released reference implementations, and invited everyone in. That openness paid off fast: within a year the major AI players had adopted it, and by December 2025 Anthropic donated MCP to the newly formed Agentic AI Foundation, a vendor-neutral home under the Linux Foundation co-founded with OpenAI and Block. There's now a public ecosystem of well over ten thousand ready-made servers — for GitHub, Google Drive, Slack, Postgres, Puppeteer, and practically everything else you can name.

The design borrows a proven idea from software tooling. If you've used the Language Server Protocol (LSP) — the thing that lets one "language server" bring smart autocomplete to VS Code, Neovim, and every other editor at once — MCP is the same trick pointed at AI. Write the smarts once; every client benefits.

The Three Pieces

MCP has a deliberately small vocabulary. Once you know these three roles, you understand the whole system.

• Host — the AI application the user actually interacts with (a desktop AI assistant, an IDE plugin, a chat app). It contains one or more clients.
• Client — the connector living inside the host that maintains a one-to-one link to a single server.
• Server — a lightweight program that exposes a specific capability: your database, your file system, a third-party API. This is the piece you most often write yourself.

The flow is simple: the host wants to do something, the client asks the server what it can do and then asks it to do things, and the server executes and returns results. Under the hood it's JSON-RPC 2.0 — plain, well-understood request/response messages — so there's nothing exotic to learn.

What a Server Actually Exposes

An MCP server can offer three kinds of things, and the distinction matters:

• Tools — actions the AI can take. "Run this query," "create this file," "send this message." Tools are model-controlled: the AI decides when to call them based on the conversation. This is where most of the power lives.
• Resources — data the AI can read. A file's contents, a database record, a log. Resources are application-controlled context, pulled in to inform the model.
• Prompts — reusable templates a user can invoke, often surfaced as slash-commands or menu items. A "summarize this PR" prompt, pre-wired with the right structure.

Tools get the spotlight because they let the AI act, but resources and prompts are what make an integration feel polished rather than bolted-on.

A Concrete Example: Our Own Server

To make this real, here's what actually happened at the top of this article. We maintain a small MCP server — call it our database connector — that we built once. It exposes a handful of read-only tools: list the available databases, list tables, describe a table's columns, and run a SELECT. Nothing more; it deliberately can't modify anything.

When the AI wanted to suggest this month's article, the conversation went roughly like this behind the scenes: the client asked our server what tools it had, the server answered with that short list, the AI decided it wanted to see what topics we'd already published, and it called the "run a query" tool with a SELECT against our articles table. The results came back, the AI read them, noticed we'd never covered MCP, and proposed it.

The important part: we wrote that server one time. We didn't teach the AI our schema. We didn't hand it credentials. And any other MCP-speaking assistant could use the exact same server tomorrow. That's the leverage.

Two Ways to Connect: Local and Remote

MCP defines how a client and server talk, and there are two main transports:

• stdio (local) — the server runs as a process on the same machine, and messages flow over standard input/output. Perfect for tools that need direct access to your files, your local database, or your dev environment. Fast, private, no network involved.
• Streamable HTTP (remote) — the server runs somewhere reachable over the network and communicates over HTTP. This is how you connect to hosted, shared services — a company's internal knowledge base, a SaaS product's official MCP endpoint.

The mental model: local servers for "things on my machine," remote servers for "services out there." The AI doesn't care which; it just sees tools.

Why This Is a Big Deal

It's tempting to file MCP under "yet another protocol," but step back and look at what it unlocks:

• Write once, use everywhere. Build an integration for your system and it works with every current and future MCP-aware AI, not just the one you had in mind.
• A real ecosystem. You rarely start from scratch. Need Slack, GitHub, or Postgres access? A community or official server probably already exists — install it and go.
• Composability. An AI can chain servers together: pull a spec from one system, check it against a database through another, and open a ticket through a third — all in one conversation.
• A clean security boundary. Because the server is a separate program you write and run, you decide exactly what it exposes. Our database server is read-only by construction; the AI literally cannot delete a row through it, no matter what anyone types.

A Word on Safety

That last point deserves emphasis, because "let the AI run tools" understandably makes people nervous. MCP doesn't hand the AI the keys to everything — it hands it the keys to exactly what your server chooses to expose. An MCP server is a gatekeeper you control:

• Scope tightly. Expose the narrowest set of tools the job needs. A reporting assistant needs SELECT, not DROP TABLE.
• Keep humans in the loop for risky actions. Good hosts prompt the user before a tool does something irreversible — sending an email, deleting data, spending money.
• Guard your inputs. Treat anything the AI passes to a tool as untrusted, and validate it the same way you'd validate input from a web form.

Handled well, an MCP server is more secure than pasting credentials into a prompt or wiring up ad-hoc scripts — because all the access flows through one auditable, purpose-built door.

Getting Started

You don't have to build anything to benefit. The fastest on-ramp:

1. Turn on an existing server. Most modern AI assistants let you enable MCP servers in their settings. Start with an official one — a filesystem or GitHub server — and watch the assistant suddenly be able to act on real things.
2. Browse the ecosystem. There are public directories of ready-made MCP servers for an enormous range of tools. Odds are the integration you want already exists.
3. Write a tiny one when you're ready. SDKs exist for Python, TypeScript, and other languages, and a minimal server that exposes one useful tool is genuinely a short afternoon's work — as our little database connector proves.

Quick Reference

Checklist for Your First Server

✅ Pick one capability to expose — start narrow
✅ Decide read-only vs. read-write (default to read-only)
✅ Define your tools with clear names and descriptions — the AI reads them to decide what to call
✅ Validate every input a tool receives
✅ Choose a transport: stdio for local, Streamable HTTP for shared/remote
✅ Test it with a real MCP host before wiring it into anything important

Conclusion: For a long time, "connect an AI to my systems" meant a pile of one-off integrations that aged badly and multiplied endlessly. MCP replaces that pile with a single, open standard — one port that any AI can plug into and any tool can expose itself through. The proof is mundane in the best way: an AI read our article history through a server we built in an afternoon and suggested this very piece, with no custom wiring on either side. That's not a demo. That's just how integration is supposed to work — and now, finally, does.