--- title: "What Is MCP and Why Product Teams Care" description: "MCP is an open standard for connecting AI applications to real systems. What it exposes, what it does not solve, and the decisions it hands a product manager." canonical_url: "https://builderscamp.com/guides/tools/mcp-for-product-managers" date_published: "2026-09-18" date_modified: "2026-09-18" author: "Andre Albuquerque, Guilherme Salgueiro" publisher: "Builders Camp" guide_class: "tools" --- # MCP for product managers, and what the protocol actually changes **TL;DR:** MCP is an open standard, announced by Anthropic on 25 November 2024, for connecting an AI application to external systems through one agreed interface instead of a custom integration per tool. It gives you three things a server can expose and two ways to connect them, and it hands product managers one decision the protocol will never make for them: what the assistant is allowed to reach and change. ## What is MCP, in one paragraph you can repeat in a meeting? The Model Context Protocol is an open standard for connecting AI applications to external systems, published with its own specification, SDKs and reference servers. Its own documentation compares it to a USB-C port for AI applications: one standard connection shape, rather than a separate cable for every device. In practice, an AI application such as Claude Code or Claude Desktop acts as the host, opens one client per connected server, and each server wraps something real: a database, a ticket tracker, an analytics product, a folder on your laptop. That is the whole idea. The reason it matters is not the elegance of the design, it is what the design removes. ## Why did a protocol appear at all? Before MCP, connecting an assistant to five tools meant building five integrations, and connecting three assistants to those same five tools meant fifteen. Anthropic's announcement named the problem plainly: every new data source required its own custom implementation, which made connected systems hard to scale. A protocol collapses that multiplication. Build one server for your tool, and every MCP-capable client can reach it. Build one client, and every published server is available to it. This is the same trade the Language Server Protocol made for code editors, and the MCP specification says so directly. It is a boring, well understood kind of win, which is a good sign. Protocols that survive tend to be boring. ## What can an MCP server actually expose? Three things, and the difference between them is the difference between reading and acting. - **Tools** are functions the model can call to perform an action: query a database, open a ticket, run a search. A tool call is the moment the assistant stops describing the world and starts changing it. - **Resources** are data the application reads as context: file contents, database records, an API response. Nothing happens to the source system. - **Prompts** are reusable templates that structure an interaction, for example a standard way of asking for a weekly summary. On the client side the protocol also defines elicitation, which lets a server ask the user for more information or for confirmation mid-task. That one is worth knowing about, because it is the protocol's own hook for putting a human back in the loop at the moment an action is about to happen rather than at setup time. Connections run over one of two transports. Stdio means the server runs as a local process on your own machine and talks to the client over standard input and output. Streamable HTTP means the server is remote, reached over the network, and authenticated, usually with OAuth. The difference is not cosmetic: a local server has your machine's privileges, and a remote server has whatever your account can do in that product. ## What changes for you, specifically? The mechanical part of connecting a server takes a few minutes and is documented by whoever published it. The part that does not take a few minutes, and that nobody else on the team will do for you, is deciding what the assistant is allowed to reach. The specification is unusually direct about this. It lists user consent and control, data privacy and tool safety as its key principles, then states that MCP itself cannot enforce those principles at the protocol level. It asks implementors to build consent flows instead. Read that as an assignment of responsibility: the protocol standardises the plumbing and explicitly declines to make the judgement call. Somebody in your team makes it, or nobody does. There is a second, quieter shift. Because tool descriptions arrive from the server and are fed to the model, the specification says descriptions of tool behaviour should be treated as untrusted unless the server is trusted. A connected server is not a passive data source. It is text that influences what your assistant does next, which is why the same specification treats a malicious or careless server as a real threat model rather than a hypothetical one. ## What does MCP not solve? It does not make the answer correct. A connection is a pipe, and a pipe carries whatever is at the other end. If your event taxonomy is inconsistent, an assistant with database access will now be confidently wrong faster than before. It does not remove integration work, it relocates it. You stop writing bespoke connectors and start maintaining access policy: which servers are approved, at what scope, reviewed by whom, and re-reviewed when the server updates. That is less code and more governance, which suits some teams and frustrates others. And it does not decide what the assistant is for. An assistant with nine connected servers and no named job accumulates capability without accumulating reliability. Naming the job first is the cheapest thing on this page and the one most often skipped. ## How fast is this moving, and what should you write down? Faster than any document about it. The specification revision dated 2026-07-28 deprecated sampling and logging, two client features that earlier servers were built against, and told new implementations to integrate with model provider APIs or log to standard error instead. An official registry of publicly available servers now exists as the discovery layer, which is itself an admission that the server list was becoming unmanageable by hand. So write down the shape, not the snapshot. The shape has held: a host application, one client per server, three server primitives, two transports, consent as a host responsibility. The list of servers you connected last quarter will be stale. The question you asked before connecting each one will not be. If you want the concrete version of that setup, [building an AI assistant with MCP](https://builderscamp.com/guides/tools/build-an-ai-assistant-with-mcp) walks through scoping a single task and connecting one server to it, and [how to design an AI agent](https://builderscamp.com/guides/tools/how-to-design-an-ai-agent) covers the layer above a single connection. ## Who should own this decision on a product team? The engineer who installs the server is the wrong default owner, for a reason that has nothing to do with skill. At install time the interesting question is whether the command runs. At use time the interesting question is whether an assistant with this reach, in this product, taking this action, is something the team would defend to a customer. Those are different questions asked at different moments by people with different information. The workable pattern is small. One named person keeps the list of approved servers and their scope. Every new connection arrives with a one sentence job, written down, and an explicit read or write answer. Anything that writes gets a second reader. Nothing about that requires a security function or a policy document, and teams that skip it usually discover the gap the same way: an assistant did something reasonable, on the wrong record, in production. ## Where this sits in a product skill path The judgement MCP hands you is an agent design problem wearing a connector's clothes: what the system may see, what it may do, when a person must approve, and what happens when it fails. Builders Camp's AI Agents bootcamp works on exactly that, over 2 weeks with 3 live sessions and 9 self-paced microlessons, and its published curriculum covers tool use and integrations, human-in-the-loop approvals and evaluation rather than any single protocol. For the build side, Building with Claude Code names MCP and tool integrations directly in its syllabus and runs 1 week with 2 live sessions under Guilherme Salgueiro. Both sit inside the AI Agentic Builders Expert Track, which bundles them with the rest of the agentic path. [See the AI Agents bootcamp](https://builderscamp.com/bootcamps/ai-agents?utm_source=guide&utm_medium=organic&utm_campaign=mcp-for-product-managers) The next decision after understanding the protocol is which servers are worth connecting at all, and the honest answer is that almost none of them are worth connecting before you can name the weekly question they would answer. Start from [what agentic coding means for product managers](https://builderscamp.com/guides/tools/what-is-agentic-coding-for-product-managers) if the agent side is new, and from [the best AI tools for product managers](https://builderscamp.com/guides/tools/best-ai-tools-for-product-managers) if you are still choosing the assistant itself. ## Frequently asked questions ### What does MCP stand for, and who controls it? MCP stands for Model Context Protocol. Anthropic announced it on 25 November 2024 and open-sourced the specification, the SDKs and a repository of reference servers. It is now an open protocol with clients and servers built by many companies, not an Anthropic-only feature. ### Is MCP the same thing as an API? No. An API is how one system exposes its functions. MCP is a layer above that: a single agreed shape for describing those functions to an AI application, so the application does not need a bespoke integration per tool. Most MCP servers are thin wrappers around an API that already existed. ### What are the three things an MCP server can expose? Tools, which are functions the model can call to do something. Resources, which are data the application can read as context. Prompts, which are reusable templates for a recurring interaction. Tools are the primitive that matters most in practice, because a tool call is the moment the assistant acts on a real system. ### Does connecting an MCP server mean the AI can change my data? Only if the server exposes tools that write and you authorise them. The specification states that hosts must obtain explicit user consent before invoking any tool, and that tool descriptions should be treated as untrusted unless the server is trusted. Many servers publish a read-only variant precisely so this question has a clean answer. ### Do I need to be technical to care about MCP? You need to be technical to build a server. You do not need to be technical to decide which systems an assistant may reach, whether it may write to them, and who reviews that decision. That second set of questions is product work, and it is the part that tends to go unowned. ### How stable is MCP as something to build a team habit on? The shape has been stable since launch: a host application, one client per server, three server primitives, two transports. The details move quickly. The specification revision dated 2026-07-28 deprecated two client features, sampling and logging, that earlier servers relied on. Build habits on the shape, not on a snapshot of the feature list. ### Does a Builders Camp bootcamp teach MCP specifically? Building with Claude Code names MCP and tool integrations directly in its published syllabus. AI Agents covers tool use, integrations and human approvals as design problems without naming a specific protocol, which is the more durable framing when the protocol layer keeps changing. ## Sources - [Model Context Protocol: What is the Model Context Protocol?](https://modelcontextprotocol.io/docs/getting-started/intro) - [Model Context Protocol: Architecture overview](https://modelcontextprotocol.io/docs/learn/architecture) - [Model Context Protocol specification, revision 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/index) - [Anthropic: Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.