What Is the Model Context Protocol (MCP)? A Plain-English Guide

Why a shared protocol matters: the N-times-M problem

Before MCP, every AI application that wanted to reach a tool or dataset wrote its own connector. If you had M AI apps and N tools, you were on the hook for up to M times N integrations, and each one drifted as APIs changed. That math is brutal. Ten apps and ten tools is a hundred fragile glue layers, each with its own auth handling, error formats, and quirks.

MCP collapses that to M plus N. Each tool ships one server that follows the spec. Each app ships one client. They speak the same language, so a new client gets every existing server for free, and a new server is instantly usable by every existing client. That is the entire economic argument for a standard, and it is the same reason USB, HTTP, and SQL won.

There is a softer benefit too. When integrations follow one contract, the surrounding concerns become learnable. Teams can reason about how the model discovers capabilities, how it requests data, and where to put controls, because every server behaves the same way at the protocol level. You stop relearning a new integration shape every Tuesday.

Clients and servers: the two roles in MCP

MCP has exactly two roles, and keeping them straight prevents most confusion. The client is the AI application, or a component inside it, that wants context and actions. The server is the lightweight process that exposes a specific domain: a filesystem, a database, a SaaS API, a search index. One client typically connects to many servers at once.

When a client starts, it connects to its configured servers and runs a handshake. It essentially asks each server, what can you do? The server replies with its catalog: here are my tools, here are my resources, here are my prompts. From that point the client knows the full menu and can decide, with the model, what to call and when.

Servers are meant to be small and focused. A good MCP server does one thing: a GitHub server handles repositories and issues, a Slack server handles channels and messages, a Postgres server handles queries against one database. This single-responsibility design keeps each server easy to audit and reason about, and it means you can grant an AI app access to one capability without handing over everything.

How MCP works, step by step

The flow above is the heartbeat of every MCP interaction. Notice where the boundary sits: the protocol governs how the request and response travel and how capabilities are discovered, but the server is fully in charge of what actually happens when a tool runs. That separation is what makes servers swappable.

Transport sits underneath all of this. MCP runs over stdio for local, same-machine servers (your editor talking to a server on your laptop) and over Streamable HTTP for remote servers reached over the network. Same primitives, same JSON-RPC messages, different pipe. A client written against the spec does not care which transport a given server uses.

The three primitives: tools, resources, and prompts

Everything an MCP server offers falls into three buckets. Get these three and you understand the protocol. Each is named, described, and discoverable, which is how the model knows what is available without anyone hardcoding it into a prompt.

• Tools are actions the model can invoke, like functions with typed inputs: create_issue, send_message, run_query. They are how an AI app moves from talking to doing, and they are the primitive most agent builders care about because they let the model change the world, not just read it.
• Resources are read-only context the server exposes for the model to consume: files, a database schema, a wiki page, the contents of a record. They give the model grounding without it having to guess, and because they are addressable, a client can pull exactly the slice it needs.
• Prompts are reusable instruction templates the server publishes so common tasks are done consistently. A code-review server might ship a review prompt; a support server might ship a triage prompt. They save teams from rewriting the same instructions and keep behavior uniform across users.
• Discovery ties them together: the client lists what exists, so adding a new tool to a server makes it instantly visible to every connected client with no app-side code change. That live, self-describing catalog is a big part of why MCP feels different from a static API key.

MCP versus bespoke integrations and plugins

It helps to compare MCP against the two things it replaces: hand-built point-to-point integrations and the closed plugin systems that came before it. The differences are not subtle once you have maintained a few custom connectors.

The plugin era taught a useful lesson: a single vendor's plugin store creates reach but also a moat, and your integration only works inside that one product. MCP keeps the reach and drops the moat. Because it is an open spec, a server you write today works in clients that did not exist when you wrote it.

None of this means bespoke integrations are dead. If you have one app talking to one internal service that will never be reused, a direct call is fine. MCP earns its keep the moment you have more than one AI surface or more than one tool, which describes almost every team building agents today.

A worked example: a support agent answering a refund question

Picture a support rep, Dana, who asks an AI agent: did order 48213 ship, and is it eligible for a refund? Without MCP, the agent would need a custom connector to the order system and another to the policy docs, each wired by hand. With MCP, the agent is a client connected to two servers: an order-system server and a knowledge-base server.

Here is the sequence. The agent discovers that the order server offers a get_order tool and the knowledge server exposes the refund policy as a resource. The model calls get_order with id 48213, gets back a structured record (shipped on June 1, delivered June 3), then reads the refund-policy resource to check the 30-day window. It composes an answer: the order shipped and delivered, and it is inside the refund window, so a refund is allowed.

Now notice the action half. If Dana says, go ahead and issue the refund, the agent would call an issue_refund tool. That is a write, not a read, and this is exactly where governance has to live. Reading an order is low risk; moving money is not. The protocol gives the model a clean way to call the tool, but it does not, by itself, decide whether that call should require a human to approve it first.

Where governance fits: actions need more than a protocol

MCP standardizes how an AI app reaches a tool. It does not, on its own, answer the harder operational questions: which user is allowed to trigger which tool, whether a write should pause for human approval, and where the record of what happened gets stored. Those controls live in the application layer around the protocol, and they matter most the instant your agent can change a CRM record, send an email, or refund a charge.

This is the line where a protocol stops and a platform begins. A practical setup wraps tool access in least-privilege roles so an agent can only touch what its job requires, routes high-impact actions through a human-in-the-loop approval step, and writes every call to an audit log you can review later. Onpilot does exactly this: AI agents connect to your CRM, support, and data tools, take action, and deliver finished work to Slack, Teams, or your app, with approvals, role-based access, and audit trails around every step.

The takeaway is not that MCP is incomplete. It is well-scoped on purpose: it solves connectivity and leaves policy to you. When you design an agent, treat the protocol as the plumbing and treat permissions, approvals, and logging as first-class features you build or buy, not afterthoughts you bolt on once something goes wrong.

Adoption: how fast MCP spread

Numbers aside, the meaningful signal is who adopted it. Within roughly a year, MCP support shipped in major AI assistants and in developer tools like VS Code and Cursor, and the spec moved under neutral, community governance. When competing vendors agree on a wire format, that is usually the moment a standard stops being one company's idea and becomes infrastructure.

Treat the exact server counts as marketing math; different registries count differently and many servers are toys or duplicates. The durable fact is that a single integration contract now reaches a large and growing set of clients, which is the only metric that changes your build-versus-rebuild calculus.

When to use MCP, and when not to

MCP is not the answer to every integration question, so here is a blunt decision framework. Use it when reuse, multiple surfaces, or a self-describing capability menu are worth the small overhead of running servers. Skip it when you have a single, throwaway connection that no one else will ever touch.

• Use MCP when more than one AI app needs the same tool, because you write the server once and every client benefits, instead of duplicating connector logic per app.
• Use MCP when you want capabilities to be discoverable, because adding a tool to a server exposes it to clients with no app-side change, which is ideal for fast-moving agent teams.
• Use MCP when you expect to swap clients over time, because an open spec keeps your servers portable and protects you from betting everything on one vendor's roadmap.
• Lean toward a direct API call when you have exactly one app talking to one internal service that will never be reused, where a server is just extra moving parts.
• Pair MCP with a governance layer whenever tools can write or take action, because the protocol carries the request but does not enforce who may run it or whether a human must approve it first.

Common mistakes when adopting MCP

Most early MCP trouble is not protocol trouble; it is design and operations trouble. A few patterns show up again and again, and all of them are avoidable with a little discipline up front.

• Building one giant server that does everything. Fat servers are hard to audit and force all-or-nothing access. Split by domain so you can grant narrow permissions, one capability at a time.
• Treating every tool as equally safe. Mixing read tools and destructive write tools without distinction is how an agent quietly does something irreversible. Tag high-impact actions and route them through approval.
• Skipping authentication on remote servers. A server reachable over HTTP without proper auth is an open door. Lock down who can connect and what each caller is allowed to do before you expose anything beyond your laptop.
• Writing vague tool descriptions. The model picks tools from their descriptions, so a fuzzy name like do_stuff leads to wrong calls. Name and describe tools precisely, with clear inputs, so the model chooses correctly.
• Logging nothing. If you cannot reconstruct which tool ran, with what arguments, on whose behalf, you cannot debug or pass an audit. Capture a trail from day one rather than retrofitting it after an incident.

The bottom line on MCP

MCP is a small idea with large consequences: agree on one way for AI apps to discover and call external tools and data, and the integration tax that has slowed every AI project drops sharply. Clients connect to servers, servers expose tools, resources, and prompts, and everything is discoverable over a standard JSON-RPC wire format. That is the whole protocol, and its restraint is a feature.

What MCP does not cover is just as important to internalize. It does not decide permissions, it does not pause risky actions for review, and it does not keep your audit log. Those are application-level responsibilities, and they become non-negotiable the moment your agent can change real systems. Get the connectivity from the standard, and build or buy the controls around it. That combination is what turns a clever demo into something you can actually run in production.