MCP became the default way AI agents connect to external data in 2025. In 2026, it’s quietly rewriting how product orgs make decisions. Here’s what’s actually happening, and what engineering leaders should be building toward.
Your engineers are using AI agents that don’t know your customers
Picture the scene. A developer on your team opens Cursor to ship a feature for an enterprise customer. The agent writes the code beautifully. Tests pass. The PR looks clean. But the agent doesn’t know which customer the feature is for, what they actually asked for, what their account balance looks like, or whether they’re at churn risk. The engineer fills the gap by Slack-messaging the PM. The PM digs through Gong calls and Salesforce notes. Two days later, the feature ships against a slightly different use case than the customer actually needed.
Every AI agent in your stack works this way. Cursor knows your codebase. Claude Code knows your docs. Glean knows your internal wiki. None of them know your customers.
MCP is the protocol that closes that gap. And in 2026, it’s quietly becoming the most important piece of infrastructure in an AI-native product org.
What is MCP, in one paragraph?
MCP, or Model Context Protocol, is an open standard created by Anthropic in November 2024. It defines how AI applications talk to external systems through a JSON-RPC 2.0 interface. Instead of writing custom integrations for every LLM-plus-tool pair, you expose your data through an MCP server, and any MCP-compatible AI client can read from it. The protocol is sometimes called “USB-C for AI applications.” One standard. Every agent.
MCP architecture has three roles. The host is the AI application the user interacts with. Claude Desktop, Cursor, an IDE, or a custom agent runtime. The client lives inside the host and handles protocol communication. The server is a lightweight program that exposes capabilities from a specific data source. A host can connect to many servers at once, each isolated in its own session.
The current state of the protocol explains why this article exists. MCP is governed by the Linux Foundation since December 2025. As of March 2026, the SDK has surpassed 97 million monthly downloads and over 81,000 GitHub stars. It’s supported by every major AI vendor: Anthropic, OpenAI, Google, Microsoft, and AWS. In a year and a half, MCP went from a niche Anthropic announcement to the default way AI agents access external data across the industry.
The reason it took off is simple. Every AI tool needed to read from external systems, and there was no standard way to do it. Every integration had to be built one-off. MCP solved the N×M problem with one protocol. Once enough major vendors signed on, the rest of the ecosystem followed quickly.
Why product orgs feel the MCP gap harder than any other function
Every other function in your company generates output that ends up in structured systems. Engineering generates code in repos. Sales generates calls in Gong. Support generates tickets in Zendesk. Product is the function that consumes signal from all of those sources and turns it into decisions. The work is integrative by definition.
Without MCP, that integrative work happens in human heads. The PM reads, synthesizes, prioritizes, writes the spec. The bandwidth of the PM is the bottleneck. Add an AI agent into the workflow and it doesn’t help, because the agent has no access to the signal the PM is integrating. The agent can write the PRD faster, but it can’t reach a more informed conclusion than the PM did.
With MCP, that integrative work happens in shared infrastructure. The same customer evidence is queryable by the PM, the engineer, the coding agent, and the CRO from the same source. The bandwidth of the PM stops being the bottleneck. The decision-making capacity of the org scales with the AI tools instead of being capped by the humans doing the synthesis.
A data point from CData’s 2026 State of AI Data Connectivity Report: 71% of AI teams spend more than a quarter of their implementation time on data integration alone. For product orgs, that ratio is even higher because the data lives in more places. CRM, support, sales call transcripts, product analytics, team Slack threads, internal docs. Each one has its own schema. Each one needs its own integration. MCP is the layer that lets you build that integration once and have every AI tool in your stack benefit from it.
The closing observation: MCP isn’t just a protocol upgrade for product teams. It’s the architecture that lets product orgs scale their decision-making at the same rate engineering is scaling its output. Without it, your roadmap quality plateaus while your shipping velocity goes up. That’s the worst possible combination.
What does MCP actually unlock for product teams?
Three real workflows. Each one is happening in AI-native product orgs right now.
Use Case 1: Cursor pulling customer context before writing code
A developer opens a Linear ticket titled “Add SAML support for enterprise customers.” Before writing any code, Cursor queries the product decision layer through MCP and pulls the list of customers who requested SAML in the last 60 days, the deal values attached to each one, and the specific security requirements they mentioned in sales calls. The agent reads the customer use cases, checks them against the existing codebase, and proposes an implementation that handles the three configurations the data shows are most common. The engineer reviews the plan, makes minor adjustments, and Cursor ships the code with the customer evidence cited in the PR description.
The technical pattern: Cursor is the MCP host. The Bagel MCP server is the source. The agent receives the same customer context the PM had when the ticket was scoped. First-pass quality goes up. Reopened tickets go down. The reviewer can see what customers the feature is for without asking the PM.
Use Case 2: Claude Code shipping with revenue evidence in the commit
An engineer pairs with Claude Code on a feature for a high-value enterprise account. Before generating the implementation, Claude Code queries the product decision layer through MCP and sees that the feature is blocking $1.2M in pipeline across three named accounts, two of which are in active renewal conversations. The agent flags this in its implementation plan, generates the code, and includes the revenue context in the commit message and the PR description. The reviewer sees what the work is worth before merging. The CRO sees a clean line from a specific shipped commit to a specific deal it unblocked.
The technical pattern: Claude Code as the MCP host. The decision layer as the source. The agent doesn’t just write code, it writes code that’s traceable to a specific business outcome. The audit trail is built into the commit history.
Use Case 3: A custom agent answering “what’s blocking the Acme renewal” across the org
A CSM asks an internal agent (built on Claude, GPT-5, or any other model, it doesn’t matter which) “what’s blocking the Acme renewal?” Without MCP, the agent has to hallucinate or refuse. With MCP, the agent queries Bagel for Acme’s open tickets, the feature requests they’ve made in the last six months, the deals they’ve referenced in calls, and the current state of those items on the product roadmap. The agent comes back with a structured answer: three blockers, two scoped on the roadmap with shipping dates, one not yet evaluated. Citations attached.
The technical pattern: a custom agent as the MCP host. Bagel as the source. The same query pattern that worked for the developer in use case 1 now works for the CSM. Same protocol, same data, different surface, different role. That’s the architectural significance of MCP. It separates the question from the tool that asks it.
Skip the build. See what an MCP-native decision layer looks like.
Bagel is the MCP-native decision layer your engineers and your coding agents read from.
What does your stack need to actually use MCP this way?
Three components.
An MCP-compatible host. Most modern AI tools already are. Claude Desktop, Claude Code, Cursor, ChatGPT, Codex, GitHub Copilot, Gemini, Gemini CLI, Windsurf, and Goose all support MCP as of early 2026. If your team is using any of these, the host side of the equation is solved. You don’t need to migrate tools, you don’t need to write custom clients.
An MCP server exposing product decision data. This is the part that doesn’t usually exist yet. Your CRM has data. Your support tool has data. Your sales call platform has data. None of them expose an MCP server that synthesizes that data into decision-level context, like “which customers asked for SAML, ranked by ARR, scoped against the roadmap.” You either build that layer or you adopt a platform like Bagel that has it.
Governance and auth. SSO integration, role-based access, audit logs. The MCP protocol supports OAuth-based flows and scoped credentials. If you’re rolling this out beyond an experimental team, the governance work isn’t optional. Decide who can query what, log every request, and scope the credentials so a leaky agent doesn’t expose customer data across the org.
A footnote on building it yourself. You can spin up an MCP server for one data source in an afternoon. The starter templates from Anthropic make this genuinely fast. Building an MCP server that synthesizes signal from Gong, Salesforce, Zendesk, Slack, Jira, and your product analytics into decision-level outputs is months of work and an ongoing maintenance commitment. The architecture is well-defined. The data engineering underneath it is the part that breaks.
What changes when MCP becomes table stakes
Forrester predicts that 30% of enterprise app vendors will launch their own MCP servers in 2026. That’s a phase change in how AI agents access enterprise data, and it has direct implications for product orgs.
In 12 to 18 months, every AI tool in your stack will read from external systems through MCP by default. The orgs that adopted the pattern early will have agents that ship with full customer and revenue context. The orgs that didn’t will have agents that hallucinate, refuse, or rely on humans to inject context manually. The competitive gap will not show up in headcount or AI budgets. It will show up in feature relevance, cycle time, and the ratio of shipped features that actually move the metric.
The architectural insight is that MCP is splitting the AI tool market into two layers. Above the protocol, you have the AI clients: Cursor, Claude Code, ChatGPT, Glean, custom agents. These are commoditizing fast. Any team can pick a different IDE or a different agent next quarter. Below the protocol, you have the data and decision layers: CRMs, product analytics, autonomous product decision layers like Bagel. These are sticky. Once your org’s product brain is built on a specific layer, the agents above it adapt to whatever surface is on top.
Quick answers about MCP for product teams
MCP (Model Context Protocol) is an open standard that lets AI applications connect to external systems through a universal interface. Instead of writing a custom integration for every AI tool and every data source, you expose your data once through an MCP server, and any MCP-compatible AI client can read from it. Created by Anthropic in November 2024, governed by the Linux Foundation since December 2025.
As of 2026, MCP is supported by every major AI client including Claude Desktop, Claude Code, Cursor, ChatGPT, Codex, GitHub Copilot, Gemini, Gemini CLI, Windsurf, and Goose. Every major AI vendor (Anthropic, OpenAI, Google, Microsoft, AWS) supports the protocol.
A developer opens a Linear ticket about adding SAML support. Cursor queries the product decision layer through MCP and pulls the list of customers who requested it, the deal values at stake, and the security requirements. The agent ships against real customer use cases instead of a vague spec. First-pass quality goes up. Reopened tickets go down.
You can. Spinning up an MCP server for one data source takes an afternoon. Building one that synthesizes signal from Gong, Salesforce, Zendesk, Slack, and Jira into decision-level outputs is months of work and ongoing maintenance. Many teams adopt a platform like Bagel that exposes a purpose-built MCP server out of the box.
Yes, when implemented correctly. The protocol supports OAuth-based authentication, scoped credentials, and audit logging. The 2026 MCP roadmap explicitly calls out enterprise readiness as a top priority, including SSO integration, gateway behavior, and configuration portability.
Engineering leaders should be making decisions now about which decision layer their agents will read from. Because in 18 months, that choice will be the most important piece of AI infrastructure their team operates.
MCP is a protocol, not a product. It works because the tools on both sides of it commit to using it. The question for engineering leaders in 2026 isn’t whether to adopt MCP. Every AI tool in your stack already supports it. The question is what’s on the other side.
Bagel exposes the product decision layer through MCP. Your team and your agents read customer evidence, revenue context, and scoped product decisions from the same source.
