MCP in plain English

Before MCP, connecting a coding agent to your ticket tracker or your internal API meant writing a bespoke integration for every single agent you used. MCP replaces that with one server and one protocol that any compliant client can speak.

The three pieces

MCP is "an open-source standard for connecting AI applications to external systems," described by its own docs with a deliberately mundane comparison: "like a USB-C port for AI applications" — one standardized connector instead of one adapter per device (modelcontextprotocol.io). Underneath that framing are three concrete primitives a server exposes:

• Tools — functions the model can call to take an action (create a ticket, run a query, send a message).
• Resources — data the client can pull in (a file, a database row, a document) without the model having to ask for it as a tool call.
• Prompts — reusable prompt templates the server ships alongside its data, so common tasks don't have to be re-written by every user.

That distinction matters in practice: a tool is something the model reaches for on its own when it decides an action is needed, while a resource is something your client chooses to hand over up front — the model doesn't have to ask for context that's already been attached to the conversation.

Why "one protocol" is the actual point

The interesting part isn't any single primitive — it's that the same server works everywhere. MCP's own ecosystem page lists Claude, ChatGPT, VS Code, and Cursor among the clients that speak it, alongside a growing list of others (modelcontextprotocol.io). OpenAI's Codex CLI documents its own MCP support the same way, configuring servers directly in ~/.codex/config.toml or via codex mcp add (OpenAI Codex MCP docs). In the figure, that's why all three connecting lines carry the same label: a server built against the spec doesn't need to know or care which client is on the other end.

What MCP is not

It is not a replacement for your API. A well-designed MCP server is usually a thin wrapper around an API or database you already have — the protocol standardizes how an agent discovers and calls that wrapper, not what the wrapper does internally. It's also not a security boundary by itself: a tool's description and its results both reach the model as plain text, which is exactly the mechanism behind MCP's known prompt-injection risks — worth its own note later in this series. And it's not required for everything: a task that only needs data you can paste into a prompt doesn't need a protocol at all.

Try it today

1. List the tools or data sources you currently copy-paste into chat by hand more than once a week.
2. Check whether a vetted MCP server already exists for that system before building one — many common tools (issue trackers, docs, search) already have one.
3. If you use Claude Code, run claude mcp add --transport http <name> <url> against a public server (Notion and Asana both publish one) just to see the tool-discovery flow work.
4. Look at what tools the server actually exposes once connected — the naming and descriptions are what the model sees, not what the README says.
5. Note which of your current copy-paste habits that server would actually replace, and which it wouldn't.

Where this breaks

• MCP adds a process (or a remote endpoint) you now have to run, monitor, and keep authenticated — it's infrastructure, not a free abstraction.
• A server with too many tools bloats every request's input tokens, since tool definitions are sent with each call regardless of use.
• Two servers can expose tools with the same name or overlapping intent, and clients don't reliably warn you when that happens.

Next: build a minimal MCP server in Python.