What Is MCP in AI? The N×M Problem That Protocols Solve

What is MCP in AI? MCP, the Model Context Protocol, is a published specification for how one program, the application running an AI model, asks another program what tools and data it offers and then calls them. The model itself never speaks MCP. The contract binds two programs, and it is published in dated revisions.

That answer fits in a standup. A search for what is MCP in AI usually returns a slogan, and this guide is for the backend engineer who needs more than one. You have seen the three letters in a vendor changelog, a colleague’s design doc and a settings tab. The guide gives you the parts, the count that explains why the thing exists, seven questions that work on any protocol, and a table of where a protocol lets strangers into your agent.

One reader spoke for many on a forum: “Funny that the ‘What is MCP?’ section doesn’t even explain what the acronym stands for… (I genuinely have no clue)” (Hacker News, 9 January 2026). So the definition comes first here, and every fact about the specification is a snapshot of the revision dated 28 July 2026, read on 7 October 2026. MCP appears as one labeled example of a category, with no syntax and no setup steps.

What is MCP in AI, in plain terms?

MCP is a contract between an application that runs a model and a separate program that offers capabilities to it. The contract fixes how the second program lists what it has, and how the first one calls an item on that list. Its own site calls it “an open-source standard for connecting AI applications to external systems” (introduction).

Three things it is often mistaken for are worth clearing away. It is a specification, so there is nothing to download called MCP; libraries and applications implement it. It is separate from the model, which only ever reads tool definitions and writes requests. And it has no owner at run time: two programs that have never met can both follow it.

In the book this site belongs to, MCP sits under a general word. Chapter 6 (its section “Protocols and Interoperability”, in the full book) treats it as the most prominent example of a tool protocol. It adds a warning I will follow: “take it throughout as one instance of a category that will keep evolving”.

For lineage, the specification points at an older relative that backend engineers know: “MCP takes some inspiration from the Language Server Protocol” (specification overview). One editor, many language servers, one contract between them.

What are the parts?

The specification names three roles, and each belongs to a different author. In its words: “Hosts: LLM applications that initiate connections”, “Clients: Connectors within the host application”, and “Servers: Services that provide context and capabilities”. The host creates “one MCP client for each MCP server” (architecture overview).

The quoted cells are the specification’s own list of what a server offers. Chapter 6 gives the same three “in one spec’s current naming”, which is a polite way of saying the names may change.

“Server” misleads people who think in machines. Chapter 6 says the role may be filled by a small process on your own laptop or by a hosted service run by a stranger, a difference it describes as carrying “enormous trust significance”. The protocol treats both the same way, and the security section below does the opposite.

What does one exchange look like in words?

One exchange has five moves, and the model takes part in only one of them. The sequence below is my paraphrase of the roles above; it leaves out message formats on purpose.

1. The host connects a client to a server, either by starting it as a local process or by reaching it over HTTP.
2. The client asks the server what it offers. The server answers with a list: each tool has a name, a description and a schema for its inputs.
3. The host turns that list into tool definitions and places them where its model can read them.
4. The model writes a request for one tool. The host decides whether to allow it, and the client forwards the call to the right server.
5. The server runs the function and returns a result, which the host hands back to the model.

Move 4 is ordinary function calling, and I will not re-teach it; the post on what tool calling in LLMs is walks through it message by message. The program around the model does the discovering in moves 1 to 3. The book’s glossary calls that program the harness.

One forum reply compressed the whole thing well: “It’s pretty much standardizing on a couple endpoints for providing a list of resources/actions/prompt templates and calling to fetch those” (Hacker News, 10 July 2025). The person who had asked answered that this is also known as documentation. Both are right, and the difference is that a program can read this documentation and act on it without a human in between.

What is the N×M problem that protocols solve?

The N×M problem is a count of integrations: every agent that must reach every system needs its own hand-written adapter, so the work grows as a product. A shared contract turns the product into a sum, because each system implements the contract once and each agent speaks it once.

Chapter 6 writes the name the other way round, as the M×N problem, and notes “you will also see it written N×M”. It counts M agents against N systems, and I follow that here. The chapter’s own example is three agents and five systems; the post on MCP vs function calling works that case and a full table of others, so this one takes a different case.

Here is a worked count with illustrative numbers. A company runs four agents: support, billing operations, a coding assistant and an on-call helper. They share seven systems: a ticket tracker, a customer database, a wiki, a code host, a data warehouse, a payments ledger and a paging service.

The calculator below opens on this case and shows the same numbers: 28 against 11, a difference of 17 pieces.

The fourth row is the one that hurts in practice. Chapter 6 says of the hand-wired design that “every adapter you already own is a living liability that breaks when either of its ends changes”. Its answer is an old one: “agree on one contract in the middle.”

Two cautions keep the count honest. It compares pieces and says nothing about hours, since one protocol server can cost more than one small adapter. It also assumes every agent needs every system, which the chapter softens to “most” of them.

What must any protocol specify?

Any protocol between an agent and something outside it has to settle seven things. They are the parties, how a capability describes itself, how it is found, how it is called, what stands at the far end, how the contract changes, and what it says about identity and consent. A specification that is silent on one of them has left that work to you.

The list is this post’s arrangement. Chapter 6 gives the material as running prose and has no checklist. Its core sentence says the agent protocols standardize how a capability describes itself, how an agent discovers it, and how it is invoked and answered across a process or network boundary. I added the questions about parties, the far end, change and consent from the chapter’s later paragraphs.

Open a specification you have never read and look for the answer to each question. Tick the ones it answers.

The last question has two halves on purpose. In my reading of the MCP specification below, the first six questions get firm answers and the seventh gets a partial one. For the second protocol I read too little of its authentication section to judge the seventh. Chapter 6 says as much about the whole category: “authorization stories mature unevenly”.

The second question hides a craft of its own. A protocol fixes where a description goes and what fields it has. What the description says, and whether a model picks the right tool because of it, is still written by a person.

How does MCP answer the seven questions?

MCP answers the first six questions in its specification and answers the seventh in part: authorization is defined and optional, and consent is left to the host. The table is a snapshot of the revision the versioning page calls current, 2026-07-28, read on 7 October 2026.

The sources are the versioning, transports and authorization pages and the overview already cited. Every row has an answer on the left. Every row also has something on the right, and the right-hand column is the review your team owes.

Row seven deserves the specification’s own words. Its page on tools says “there SHOULD always be a human in the loop with the ability to deny tool invocations” (tools), and its overview concedes that the protocol cannot enforce such principles itself. A “should” addressed to implementers is a request. Whether your host honors it is something you check.

The revision also covers how long a call may run. Its page on cancellation says implementations “SHOULD establish timeouts for all sent requests” and defines how a client abandons a request, and its tools page asks clients to “Implement timeouts for tool calls” (cancellation). It sets no number, so the value is yours.

How does a second protocol answer the seven questions?

A second protocol answers the same seven questions with different nouns, which is the test that the list describes protocols in general. The example is Agent2Agent (A2A), an agent-to-agent protocol, described here only from its own specification page, which showed “Latest Released Version 1.0.0” on 7 October 2026.

The specification introduces itself as “an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems” (A2A specification). I could not verify the release date of that version from the pages I read, so none is given.

• Parties. A client agent and a remote agent, which the specification calls an A2A Server.
• Self-description. An Agent Card: “A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements.”
• Discovery. The card is published so that other agents can fetch it.
• Invocation. The client sends a message, and the work is tracked as a task that it can get, list, cancel or subscribe to.
• The far end. An agent that reasons. The specification says it is “Designed for (potentially very) long-running tasks and human-in-the-loop interactions”, and it names a principle of opaque execution: agents collaborate “without needing to share their internal thoughts, plans, or tool implementations.”
• Change. Numbered versions, with breaking changes from the previous one listed in an appendix.
• Identity and consent. The card declares authentication requirements. I did not read the authentication section in detail, so I say no more than that. Whether you trust what the remote agent does with your task is left to you.

Question five is where the two protocols part. Chapter 6 opens its account with that line: “Two kinds of protocol matter here, and they differ in what stands at the far end of the wire.”

A2A’s own material agrees. Its specification calls the pair “complementary protocols designed for different aspects of agentic systems” (A2A specification, Appendix B), and its comparison page summarizes: “MCP is vertical. It deepens a single agent.” and “A2A is horizontal. It connects agents across that boundary.” (A2A and MCP).

The same seven questions also work on something that never called itself an agent protocol. An internal REST API with a machine-readable description answers self-description and invocation well. It is usually quiet on discovery at run time and on what the far end is allowed to do for a model, and that silence tells you what you would have to build.

What does a protocol leave unsettled?

A protocol settles how two programs talk and leaves four things open: who is calling, who consented, whether the far end deserves trust, and how much of the model’s attention the tool list consumes. Chapter 6 puts the central one in a clause: “Standardizing the interface does not standardize the trustworthiness of what is behind it”.

Identity. The MCP revision read here makes authorization optional and defines it only for HTTP connections. A local server gets whatever credentials sit in its environment, which are often the developer’s own. Which credential each server holds, and how narrow it is, is a decision the protocol never sees.

Consent. The specification asks implementers to keep a person able to deny a call. It cannot make a host show the full arguments, or the full description, before that person clicks. An approval screen that hides either one is a formality.

Trust in the far end. A conforming server is a server that follows the message format. Conformance says nothing about its author’s intentions or its code quality. One forum commenter drew the working line: “I think many devs misunderstand MCP because they work in solo mode. In solo mode, you just have your secrets local. You don’t care about auditing access.” (Hacker News, 21 September 2026).

Context cost. Every tool a host loads is text in the model’s context, and several servers can add up to a long list. How much is loaded, and when, is the host’s policy. A commenter made the point sharply: “The idea that MCP tool definitions take up a certain number of tokens is laughable. That’s an implementation detail of the agent harness.” (Hacker News, 30 May 2026).

I print no token figures here, because the ones I found were readers’ reports and estimates. The post on when a tool should become a skill prices that standing cost and shows the loading policies that reduce it.

Where does a protocol let strangers into your agent?

A protocol lets strangers in through two openings: the words a server publishes, which the model reads, and the code a server runs, which acts with whatever access it was given. Chapter 17 (its section “The Supply Chain”, in the full book) compresses the change into six words: “The supply chain now ships instructions.”

This section is defensive. It names each threat, where it enters and what limits it, and it contains no attack steps. The first threat has its own figure in the book.

Tool poisoning means that a tool’s description carries instructions meant for the model. The description is loaded into context with everything else, so in Chapter 17’s words “a poisoned one is a standing injection that arrives at install time and attacks on every run thereafter”. It belongs to a wider family, covered in the post on indirect prompt injection attacks, in which the instruction arrives inside content the agent reads. The glossary has an entry for prompt injection; it has none for tool poisoning, which is Chapter 17’s term and the trade’s.

The table is this post’s arrangement. The controls come from Chapter 17’s closing discipline and the specification’s security guidance, except in the third row, where they are my own inference. Pick a kind of evidence to narrow it.

Chapter 17 supplies most of the third column in one paragraph. It asks you to “re-review on update, because an updated capability is a new capability”. It continues: “Give each tool its own scoped credential, never your master key, so that one poisoned link in the chain forfeits one small thing.” For anything unfamiliar: “Try unfamiliar connectors against fake data inside a hard sandbox before they meet anything real.”

What do the outside write-ups actually show?

The outside write-ups show three demonstrations by researchers and one description without an experiment, one disclosed and fixed vulnerability, and one incident reported by the company that was impersonated. Each is described below as its authors describe it, with its date, because a demonstration and an incident are different kinds of evidence.

• Demonstration, 1 April 2025. Luca Beurer-Kellner and Marc Fischer of Invariant Labs published a security notification naming tool poisoning, which they call “a specialized form of indirect prompt injections”. Their experiments ran against one client application. They recommend that tool descriptions be “clearly visible to users” (Invariant Labs).
• Demonstration, same write-up. The authors also demonstrate one server’s description altering how an agent uses a trusted server’s tool. They describe, without an experiment, a server changing a description after approval, which they call a rug pull. Their summary: “an agentic system is exposed to all connected servers and their tool descriptions”.
• Demonstration, 26 May 2025. Marco Milanta and Luca Beurer-Kellner of Invariant Labs showcase an agent steered by text in a public issue on a code-hosting site, reached through that platform’s server. They write that “this is not a flaw in the GitHub MCP server code itself, but rather a fundamental architectural issue that must be addressed at the agent system level” (Invariant Labs).
• Disclosed vulnerability, 9 July 2025. Or Peles of JFrog Security Research disclosed CVE-2025-6514 in a connector utility, which could run operating-system commands on the user’s machine when it connected to an untrusted server. JFrog rated it critical and reports a fixed version. Its advice: “Only connect to trusted MCP Servers, using HTTPS” (JFrog).
• Reported incident, 25 September 2025. Postmark stated that “A malicious actor created a fake package on npm impersonating our name, built trust over 15 versions, then added a backdoor in version 1.0.16 that secretly BCC’d emails to an external server.” It adds that “Postmark had absolutely nothing to do with this package” (Postmark).

Three gaps belong beside that list. The JFrog rating is the discoverer’s own; the public vulnerability database entry did not load when I checked. The Postmark page gives no count of affected users, so I give none. And I read the incident as a change after approval, fifteen clean versions and then a different one; that label is mine.

The fourth row of the table rests on the specification as well. Its security page says local servers “are binaries that are downloaded and executed on the same machine as the MCP client”, and asks clients to run them “in a sandboxed environment with minimal default privileges” (security best practices). The glossary entries for sandbox and confused deputy cover the two older ideas involved. Chapter 17 calls the shared-server version of the second “an ordinary authorization bug wearing new clothes”.

Two limits apply to the third column. A code review of a server proves things about its code and nothing about the data it will carry. Chapter 17 quotes one vendor’s guidance on that: “An audited connector isn’t the same as audited data.” And approval at install time ages. For a remote server, the chapter says, “your install-time approval quietly decays”.

How common any of this is, I can only partly say. One academic scan of public servers exists, and the MCP vs function calling post reports its figures with their caveats. For the fifth row, the lethal trifecta audit checks the combination a new server would create.

Do you need a protocol at all?

You need no protocol for one agent that calls one system when your team owns both; a function in the agent’s own code does that job with less to maintain. An honest answer to what is MCP in AI includes that case. A protocol starts to pay when several agents share several systems, or when someone else owns one end of the connection.

The third case is a far end that reasons. Another team’s agent that takes a goal and reports back later calls for an agent-to-agent protocol and a written brief. Chapter 6 states the general condition: “protocols earn their ceremony with many connections and third-party reuse”.

That is the short rule. The companion post has the full decision, with the arithmetic for the break-even point and a pre-install review for a server someone else wrote, and the two agree by design.

Can I paste the seven questions into a design doc?

Yes: the block below is the checklist as plain text, with a line for the answer and a line for what is left to your team. It is a template, so change the wording to fit your review process.

PROTOCOL REVIEW: <protocol name>, revision or version <...>, read on <date>
Far end: <system or agent>, owned by <team or vendor>

1. Parties. Who are the two sides, and what does each one promise the other?
   Spec says:
   Left to us:
2. Self-description. How does a capability say what it is, what it takes and what it returns?
   Spec says:
   Left to us:
3. Discovery. How does one side learn what the other offers, and can that list change while the agent runs?
   Spec says:
   Left to us:
4. Invocation. How is a capability called and answered, in what message shape, in what order, over what connection?
   Spec says:
   Left to us:
5. The far end. What stands on the other side: a function that executes, or something that reasons? And how long may it take to answer?
   Spec says:
   Left to us:
6. Change. How are versions named, what counts as a breaking change, and how does each side notice?
   Spec says:
   Left to us:
7. Identity and consent. What does the protocol say about who is calling, with which credential, and who approved the action? What does it leave to you?
   Spec says:
   Left to us:

Threats reviewed (entry point -> control -> owner):
- Descriptions read in full by:
- Version pinned at:            Re-review on update owned by:
- Credential scope:
- Sandbox for local code:
- Results treated as untrusted input: yes / no
- Trifecta audit done on:

Limits of this guide

This guide answers what is MCP in AI for one dated revision, so its details will age faster than its questions. Every statement about MCP comes from the revision dated 28 July 2026, and every statement about A2A from the version its site showed on 7 October 2026. Chapter 6 gives the instruction that follows from that: “Version your integrations and expect breakage.”

The A2A walk is shallower than the MCP one. I read its overview, its definitions and its comparison page, and I did not read its authentication section closely, so the seventh answer there is thin on purpose.

The security evidence is uneven. Most of it is researchers showing that something can be done; one item is a fixed vulnerability and one is an incident reported by an affected company. I found no public count of how often teams are harmed this way, and I left out the researchers’ original write-up of that incident because its address now leads to an unrelated page.

Finally, the count has limits. It measures pieces, it assumes every agent needs every system, and it says nothing about quality. A shared server that every agent uses badly is still one implementation.

The takeaway

The short answer to what is MCP in AI is a contract. A protocol is an agreement between programs, MCP is the best-known current example for tools, and the seven questions tell you what any such agreement fixes and what it hands back to you. Chapter 6 ends its section with the compressed form of the risk: “every socket is a door.”

The count, the two kinds of protocol and the ledger of their costs are in Chapter 6, Skills, Protocols, and Interoperability (in the full book), and the supply chain is in Chapter 17, Security, Safety, and Guardrails (in the full book). The Preface, Chapters 1 and 2 and the glossary are free to read online. The free guide to tools, skills and protocols collects the neighboring posts and tools, and you can see the formats.