glossary · ai
Model Context Protocol (MCP) definition for product managers
An open standard, now governed by the Linux Foundation, that lets AI clients and tool servers connect through a single shared protocol instead of one custom integration per pair.
MCP is a wire protocol, not a product feature. It defines a standard way for an AI client (your application or an agent runtime) to discover and call external tools and data sources, so that each side implements the protocol once rather than building a custom connector for every pair. The canonical framing: MCP does for AI tool connections what USB-C did for device cables. One port, many devices. The tradeoff the analogy hides is that USB-C carries power and data in a physically constrained path; MCP carries instructions that an LLM interprets, which makes the attack surface larger and the failure modes subtler. PMs who only know the analogy fail the follow-up.
Anthropic launched MCP in November 2024 as an open standard over JSON-RPC 2.0. In March 2025 it donated governance to the Linux Foundation’s Agentic AI Foundation (AAIF), with founding members including OpenAI, Google, Microsoft, Amazon, Cloudflare, Block, and Bloomberg. The protocol is not Anthropic-proprietary. As of mid-2026: 97 million monthly SDK downloads, 10,000+ active production servers, roughly 150 AAIF member organizations, and Forrester predicting 30% of enterprise SaaS vendors would ship MCP servers in 2026.
The N×M problem MCP solves
Before MCP, connecting N AI clients to M tool servers required N×M custom integrations. Each client needed bespoke code for each tool; each tool needed bespoke code for each client. MCP collapses that to N+M: each client implements the protocol once, each server implements the protocol once, and the two can talk without a dedicated adapter. This is why the spec attracted rapid cross-vendor adoption; the incentive structure favors everyone who ships tools or builds clients.
The three-part architecture
Every MCP deployment has three roles.
- Host: the application that controls the conversation context and orchestrates one or more clients. Your AI product or agent runtime is typically the host.
- Client: a module inside the host that manages a persistent connection to one MCP server. One host can run multiple clients simultaneously.
- Server: the process that exposes tools and data to the client. Your CRM, ticketing system, code repo, or any API you want the agent to reach can be wrapped in an MCP server.
Transport matters here. SSE (Server-Sent Events) is deprecated as of spec version 2025-06-18. The current standard is Streamable HTTP. If a candidate or vendor cites SSE as the transport layer in 2026, that is a signal they have not kept up with the spec. Interviewers probe this specifically.
The five primitives and who controls each
This is the detail PM candidates most often get wrong. MCP defines five primitives with distinct ownership models, and the control owner determines where your product governs behavior versus where the model does.
| Primitive | Controller | What it does |
|---|---|---|
| Tools | Model-controlled | Callable actions the LLM decides to invoke: query a database, send a message, update a record |
| Resources | Application-controlled | Named data the app exposes for the model to read: a file, a document, a database row |
| Prompts | User-controlled | Reusable instruction templates the user selects and invokes |
| Sampling | Server-to-host | The server requests that the host run a model inference call on its behalf |
| Roots | Host-to-server | URI or filesystem boundaries the host declares, scoping what the server can traverse |
Tools are model-controlled: the model decides when and whether to call them, based on how well the tool description and input schema match the task. A poorly written tool description means your server gets skipped. Resources and prompts are app- or user-controlled: the application decides what data is in scope and the user decides which templates apply. Mixing these up in an interview signals the candidate has not read past the summary page.
A sixth primitive, Tasks (SEP-1686), shipped experimentally in 2026 to support long-running agentic handoffs. A .well-known metadata format is also being added so servers are discoverable without a live connection, which matters for enterprise procurement catalogs.
MCP vs. RAG vs. fine-tuning: where each lives in the stack
These solve different problems and often run together in production.
RAG retrieves indexed, often static content from a vector store and injects it into the model’s context at query time. Good for knowledge bases, documentation, and content that changes infrequently but is too large to fit in a prompt. MCP provides on-demand access to live systems via structured tool calls. Good for real-time data, write operations, and any system the model needs to query or act on mid-task. Fine-tuning changes the model’s weights to shift its default behavior. Good for style, format, and domain conventions, not for facts that change, and not for live system access.
In a typical production agent stack: fine-tuning sets the behavioral baseline, RAG provides document-grounded context, and MCP gives the agent its action surface. Treat them as complementary, not competing.
The PM’s three decisions
There are three MCP decisions PMs own, and they are distinct.
Build an MCP server for your product. This makes your product callable by AI agents that users configure externally, including Claude, GPT-4o, and other agent runtimes. It is a distribution play: if your product is not in the tool catalog, it does not get called. In 2026, enterprise buyers increasingly ask whether a SaaS product ships an MCP server before signing. Building one lets you validate agent integration demand before committing to native agentic features; the MCP surface area tells you which tools agents actually use, which is discovery data for roadmap prioritization.
Use MCP to connect your AI feature to third-party tools. If you are building an agent, MCP is how you give it structured access to external systems without writing N×M custom integrations. The PM decision here is which tools to expose, with what permission scopes, and how to audit what the agent did.
Mandate MCP support in vendor procurement. If your organization is evaluating SaaS tools that your agents will need to reach, “does this vendor ship a production-grade MCP server” is a valid selection criterion. Not all MCP servers are equivalent: check for scoped permissions, audit trails, and transport compliance (Streamable HTTP, not SSE).
Security risks PMs should know to raise
Wiz documented six categories of MCP security incidents. PMs do not need to audit code, but they need to ask the right questions before a server ships or a vendor gets approved.
- Indirect prompt injection via resource content: a malicious document in a resource can instruct the model to take actions the user did not intend. Ask: does your MCP server sanitize resource content before it reaches the model’s context?
- Tool name shadowing: a malicious MCP server can define a tool with the same name as a trusted one, causing the model to call the wrong implementation. Ask: how does the host validate tool provenance when running multiple servers?
- Cross-tenant data leakage: shared MCP server infrastructure without strict tenant isolation can return one customer’s data to another. Ask: how are resource scopes isolated per user or tenant?
- OAuth PKCE omissions: incomplete auth flows leave tokens exposed. Ask: does your server implement the full PKCE flow?
- Auto-run code execution: some tools execute code on invocation without confirmation. Ask: which tools are irreversible, and does the host require confirmation before calling them?
- RCE via dependency chain: MCP server packages have been compromised through malicious dependencies. Ask: what is the supply chain verification process for server packages?
These are the questions an informed PM raises in design review. Interviewers at security-aware enterprise AI companies expect PM candidates to know the categories, not the implementation details.
Governance and spec stability
The AAIF organizes the spec roadmap around four Working Groups: Transport and Scalability, Agent Communication, Governance Maturation, and Enterprise Readiness. The Working Group structure means significant spec changes now go through formal review, which increases stability compared to the Anthropic-controlled 2024 era. The SSE deprecation was the last major breaking transport change; the Working Group model is designed to prevent unannounced breaks of that scale. This is relevant for build-vs-buy decisions: the governance shift reduces the risk that a bet on MCP gets stranded by a unilateral spec change.
Interview answers
strong
"MCP is an open protocol governed by the Linux Foundation's AAIF since March 2025, with Anthropic, OpenAI, Google, Microsoft, and Amazon as founding members. It standardizes how AI clients connect to external tools and data sources: instead of N×M custom integrations, each side implements the protocol once. The five primitives have distinct control owners: tools are model-controlled callable actions, resources are application-controlled data, prompts are user-controlled templates, sampling lets a server invoke a model call via the host, and roots let the host scope what the server can traverse. Current transport is Streamable HTTP as of the 2025-06-18 spec; SSE is deprecated. As a PM, I own three decisions: whether to build an MCP server so our product appears in agent tool catalogs, which tools to expose and with what permission scopes when building our own agent, and whether to require MCP compliance in vendor procurement. On security, I ask about prompt injection via resource content, tool name shadowing across multiple servers, and cross-tenant isolation on shared infrastructure."
weak
"MCP is Anthropic's protocol for connecting AI to APIs." It is not Anthropic-proprietary (governance moved to the Linux Foundation in March 2025). Calling it an "API connector" misses the primitive and control-model distinction entirely. And the candidate who stops there has no answer when the interviewer asks who controls tool invocation, what the current transport is, or what security risks a PM should raise. This answer passes the first five seconds and collapses on every follow-up.
The 2026 frame
In 2026, connecting a model to a database is not the hard part. Any reasonably capable engineering team can do it. The question is whether your product is viable as an agent-native integration point and whether the experience is reliable enough that agents (and the users who configure them) choose your MCP server over a competitor’s. A product without a production-grade MCP server, scoped permissions, an audit trail, and clear tool contracts may not appear in enterprise agent catalogs at all. PMs who understand MCP can frame the build-vs-buy decision, write the tool contracts, and defend the security posture. That is what interviewers at Anthropic, OpenAI, and enterprise AI companies are probing for.
For the broader agent architecture context, see agent and RAG. For how to position MCP alongside the other AI stack decisions, see RAG vs fine-tuning vs prompting.