MCP (Model Context Protocol)

Inside eighteen months, “we support MCP” went from a line in a changelog to a checkbox on enterprise procurement forms. The speed of that adoption has done something predictable to the vocabulary. People now use MCP as a loose synonym for “our product works with AI.” That covers a chat widget, a data export, and a system with write access to your roadmap. Those are not the same thing, and the protocol underneath is far more specific than the marketing around it suggests.

What is the Model Context Protocol (MCP)?

The Model Context Protocol is an open standard that lets AI applications connect to external tools and data through one common interface rather than a custom integration for every pairing. It specifies how a system exposes tools, data, and prompt templates, and how an AI client discovers and calls them.

Anthropic introduced the protocol in November 2024. The Agentic AI Foundation, a directed fund under the Linux Foundation, governs it now. It defines a client-server relationship: an AI application acts as a host, opens a client connection, and talks to a server that offers up whatever context and capability it chooses to expose.

Worth being precise about the scope. MCP is a wire format and a set of conventions. It does not make a model more capable, it does not decide what the model should do, and it does not manage the reasoning that happens once data arrives. It solves one problem: getting a model reliable access to things that live outside it, in a way that any client can understand without bespoke work. Everything interesting that people credit to MCP is actually the combination of the protocol plus an AI agent doing the deciding.

Why was MCP created?

Before a shared standard existed, every AI application that wanted to reach an external system built that connection itself, and every system that wanted to be reachable built a connector per application. The arithmetic gets ugly fast, and it explains why the standard spread the way it did.

Anthropic donated MCP to the Agentic AI Foundation in December 2025, where it sits alongside goose from Block and AGENTS.md from OpenAI as founding projects, with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg. More than 10,000 public MCP servers were running by then. ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code had all adopted it. Competing vendors handing a protocol to neutral governance is what moves it from one company’s bet to shared infrastructure.

The integration math that made a standard inevitable

Five AI applications wanting to reach twenty tools is a hundred separate integrations, each with its own auth, error handling, schema, and maintenance burden. Each one is small. Collectively they are the reason “AI that knows about your product” stayed a demo for so long. A shared protocol turns a hundred integrations into twenty-five: each application implements the client once, each system implements a server once, and anything on one side can reach anything on the other.

That is the same structural argument that made APIs worth standardizing two decades earlier, applied to a new caller.

How does MCP work?

Three participants, two layers, three things a server can offer. That is the whole shape of it, and knowing the shape is enough to have a useful conversation with your Engineering team about what they are proposing to build.

Hosts, clients, and servers

The architecture names three roles. The host is the AI application, something like a desktop assistant or a coding tool. The host spins up one client per connection it wants to maintain. Each client talks to one server, which is the program exposing context and capability.

A server can run locally on the same machine as the host, or remotely on a vendor’s platform. A product team’s MCP server, the one that lets an assistant reach their product, is almost always the remote kind. The distinction shows up in the transport, and it shows up in the security review.

What a server actually exposes

The protocol defines three server primitives, and the difference between them is about who decides when they get used.

Tools are executable functions. Searching records, creating an item, updating a field. The model controls tools. It reads the tool’s name, description, and input schema, then decides on its own whether to call it. Nobody approves each call in advance.

Resources are data sources the client attaches as context. A file, a schema, a record. Resources are application-controlled, so the host decides what gets pulled in.

Prompts are reusable templates that structure an interaction, surfaced to the user as something like a slash command. A person controls prompts and picks them deliberately.

That control hierarchy is the single most useful thing in the specification for a Product Manager, and it is almost never mentioned in vendor copy. When somebody proposes exposing a capability through a server, ask which of the three it should be. The answer determines who decides when it fires: a human, an application, or a statistical model.

How the connection works

Underneath, the protocol runs on JSON-RPC 2.0 over one of two transports: stdio for a server running locally on the same machine as the host, and Streamable HTTP for remote servers, which supports standard authentication including bearer tokens and OAuth. The specification is still moving, with the 2026-07-28 revision making the protocol core stateless, so any team maintaining a server should version deliberately rather than assume today’s behavior holds.

What is the difference between MCP and an API?

This question comes up in every internal conversation about building a server. Someone usually phrases it as “we already have an API, why do we need this.” The two are not alternatives. The distinction is about who does the calling.

Code that a developer wrote calls an API. That developer read the documentation, chose the endpoint, handled the response shape, and wrote the error handling. Every call is deliberate, and the code fixes every path before runtime.

A model calls an MCP server. The model reads the tool descriptions at runtime, infers which tool matches the intent in front of it, constructs the arguments, and interprets whatever comes back. Nobody wrote that call in advance. The same request can produce a different sequence of calls on different days.

	API	MCP Server
Called by	Code a developer wrote	A model reading tool descriptions
Path chosen	By the developer, in advance	By the model, at runtime
Same input, same output	Yes	Not guaranteed
Errors read by	The calling code	The model, as text
Descriptions matter to	Whoever maintains the code	Whether the right tool gets called at all

Two consequences follow, and both are product decisions rather than engineering ones.

Tool descriptions become user-facing copy. A description is the only thing the model has to decide whether a tool applies. Ambiguous naming does not produce a compile error; it produces a model quietly calling the wrong thing and reporting success. Teams that treat descriptions as internal documentation get exactly the failure mode you would expect.

Error handling has to be legible to a reader rather than a parser. An API can return a status code because the calling code knows what to do with it. A model handles an error by reading it, so a server that returns an opaque failure will produce an assistant that invents an explanation and carries on.

In practice, most MCP servers sit on top of an existing API rather than replacing it. The server is a translation layer with a different audience.

What does MCP change for product teams?

The protocol arrived as an engineering story and turned into a product one within a year. Three things change, and only one of them is technical.

Your product becomes reachable by tools you never integrated with

Shipping a server means anyone using a compliant client can reach your product without you building anything for that client specifically. That is the upside, and it is genuine. It also means your product now appears inside workflows you did not design, next to tools you did not choose, being described to a model by text you wrote once and probably have not revisited.

Customer expectations move faster than most roadmaps here. Introducing the ProdPad MCP in her All the Things webinar, Head of Product Julie Hammers described it as probably the most requested feature she had heard about in her time at the company. Demand for a protocol connection tends to arrive as inbound feature requests rather than as a technology trend somebody has to sell internally, which changes who in your organization is asking for it and how quickly.

Context quality stops being an infrastructure concern

A model connected to your systems inherits your information architecture, including the broken parts. If strategy lives in a deck, goals live in a spreadsheet, the roadmap lives in a delivery tool, and customer feedback is spread across three inboxes, then an assistant asked why a piece of work exists has nothing coherent to read. It will answer anyway, assembled from whatever it could reach, and it will sound confident.

This is why teams comparing AI features by comparing models are usually measuring the wrong variable. The protocol makes reach cheap. Whether the thing being reached is connected, current, and traceable is a separate problem, and it is the one that determines output quality.

The surface area question becomes a product decision

Every tool a server exposes enlarges what a model can do and enlarges what it can get wrong. Servers that expose fifty narrowly-scoped tools produce models that pick badly among them. Servers that expose five broad tools produce models that cannot do the specific thing a user asked for. Getting that granularity right is ordinary product work: understanding the jobs people are actually trying to do and shaping the interface around them.

What are the security risks of MCP?

Every risk here comes from the same property that makes the protocol useful: a model, not a developer, decides which tool to call and with what arguments. The OWASP MCP Security Cheat Sheet is the most practical starting point, and the categories it names should be familiar to anyone signing off on an integration. The risk lives in the autonomy rather than the connection, which is why a server exposing read-only search sits in a different category from one that can write to your backlog.

Prompt injection and tool poisoning. A model reads tool descriptions and tool output as instructions. Instructions hidden in either can redirect its behavior. Poisoned metadata is particularly awkward because it is invisible in the interface a user approves, and the content that carries an injection often arrives through a perfectly legitimate channel: a support ticket, a scraped page, a message in a connected workspace.

The confused deputy problem. A server frequently executes actions with its own broad privileges rather than the requesting user’s narrower ones. Anyone who can get the model to make a request inherits the server’s access rather than their own.

Over-scoped tokens. Servers that request full access where read-only would do create an aggregation risk that compounds with every server a team adds.

Supply chain exposure. Servers are software that someone downloads and runs. Research from the Cloud Security Alliance has documented agentic development tools auto-launching project-defined servers with the developer’s full privileges on opening a folder, which turns a crafted repository into a code execution path.

The organizational failure underneath all of these is consistent. Teams adopt servers through the same informal route they adopt browser extensions, one developer at a time, and nobody holds a list of what is connected to what. The mitigation is unglamorous: an inventory, least-privilege scopes defined per tool rather than per server, a named human checkpoint before anything external changes, and an audit trail that records the reasoning alongside the action. That last one stops being optional the moment you sell into a regulated market.

How do product teams use MCP in practice?

The demos are impressive and mostly not what teams end up running. The workflows that survive contact with a real week share a shape: high-volume work with a recoverable cost of error, where a person still reads the output before anything ships.

Interrogating the backlog and the roadmap

Asking what is in the Now column and what the target outcome is for each item, then getting an answer in the tool where the conversation is already happening. This is the use case product leaders reach for first, because it removes the need to log in and click through to answer a question someone asked in Slack. It works because a Now-Next-Later roadmap already encodes the reasoning; the protocol just exposes it.

Feedback triage and theming

Customer feedback management breaks at volume because reading everything is a job nobody has. A model with access to the feedback inbox can group incoming items into themes, check which themes have ideas attached, and flag the gaps. In her walkthrough of the ProdPad MCP, Julie Hammers ran exactly this, then had the assistant create an idea for an uncovered theme and link the supporting feedback to it. The step that makes it useful is the linking, not the summarizing.

Spotting misalignment across products

Asking which initiatives are linked to a given objective, and which are not, turns an audit that nobody schedules into a question that takes a minute. The answers tend to be uncomfortable, which is the point.

Drafting with real evidence attached

First drafts of specs, release notes, and stakeholder updates are predictable in structure and tedious to start. Drafted against live product data rather than a blank prompt, they arrive close enough to edit. The editing is where the Product Manager’s judgment shows up, and handing that step to the model is how teams end up with documents nobody reads.

Why MCP turns an AI question into an operating model question

The protocol has effectively solved access. Connecting an AI application to a product system is now a configuration task rather than a project, and the cost of that connection will keep falling. What it has not solved, and cannot, is whether the thing on the other end of the connection is worth reading.

An assistant reaching into a product organization can only reason about the relationships that exist in the systems. If an initiative is not linked to the objective it serves, no model will infer the link. If the customer evidence behind a decision lives in someone’s inbox, no protocol will surface it. If the reason a bet was made was discussed in a meeting and never written down, the answer to “why are we building this” gets reconstructed from whatever fragments were reachable, and it arrives sounding authoritative.

That turns MCP into an argument for something most product teams have been putting off. The value of connecting AI to your product work is bounded by how well that work is connected to itself. Teams that have been carrying scattered strategy, orphaned objectives, and undocumented decisions have been paying for it quietly in onboarding time and stakeholder confusion. Connecting a model makes the cost loud.

ProdPad holds that layer on purpose. Strategy, objectives and key results, roadmap initiatives, customer feedback, and the reasoning attached to each of them live in one connected system, which is what makes an AI client reaching in through MCP useful on your product rather than generically fluent about products.