MCPs Are Not for Development

MCP has become the darling of the developer tooling world. Cursor, Claude Code, VS Code, Windsurf. Anthropic's SDK alone sees 97 million monthly downloads. The Model Context Protocol is everywhere in engineering workflows, and the conversation around it has centered almost entirely on how developers use it to wire AI into their coding tools.

And that's probably the least interesting thing about it. Development isn't where MCP creates the most value. Developers already have CLIs, APIs, and direct integrations that are faster and more purpose-built for what they do. MCP's real power is somewhere else entirely, and most of the ecosystem hasn't caught on yet.

Why Developers Don't Actually Need MCP

Developers have direct API access, CLIs, and SDKs for virtually every system they interact with. These tools are purpose-built for programmatic integration. They're fast, well-documented, and designed for the exact workflows engineers use every day.

MCP adds an abstraction layer on top of those same systems. When you already know how to call an API endpoint, wrapping it in an MCP server introduces overhead without meaningful benefit. You're adding a middleman to a conversation that was already working fine.

Where MCP is genuinely useful for developers is discovery. If you're unfamiliar with a system, an MCP server can teach you how it works, what endpoints exist, what data is available, and how things connect. It's a great onboarding tool for exploring an unfamiliar platform through natural language. But once you know the system, you drop back to CLI and direct API calls because they're simply more efficient.

This isn't a criticism of the protocol. It's a recognition that MCP was designed to solve a different problem than developer productivity. And that different problem is significantly more valuable.

The Problem MCP Actually Solves

Non-technical users can't call APIs. They can't use CLIs. They don't write code. But they increasingly need AI tools grounded in real business data to do their jobs effectively.

Without something like MCP, every connection between an LLM and a business system requires custom development. That means every business team (sales ops, marketing, HR, finance) waits in the dev queue for context their AI tools need. And that queue is already long.

MCP provides structured, easily managed, and generally safe context awareness for LLMs. It's a standardized connector that an admin can configure, IT can govern, and security can audit. The protocol handles the plumbing so that connecting an AI agent to a business system becomes a configuration task, not a development project.

The value proposition isn't "another integration option for developers." It's "the first integration option for everyone else."

Permissions-Backed Context Is the Real Story

The word "safe" in that description matters more than it might seem. MCP connectors come with permissions, scoping, and governance built into the protocol itself.

When a sales ops lead connects their CRM data to Claude through an MCP server, that connection respects existing permission boundaries. The LLM sees what that user is authorized to see. Not more. This isn't a raw data pipe. It's a governed, permission-backed context layer that IT can actually manage and security can actually audit.

Compare that to the alternative happening right now in most organizations. Business users are copying data into ChatGPT prompts, pasting spreadsheets into chat windows, uploading documents with no access control and no audit trail. That's shadow AI, and it's the inevitable result of not having structured connectors. MCP replaces the workaround with something governed.

That number makes sense when you think about it this way. The value isn't in the protocol itself. It's in giving non-technical teams safe, governed access to the context their AI agents need to be useful.

What This Looks Like Inside Salesforce

Salesforce added a native MCP client in July 2025. Agentforce speaks MCP natively, which means the platform's AI agents can reach external systems through standardized connectors without custom integration code.

The people setting up these connections aren't writing Apex. They're Salesforce admins and architects using the setup UI to configure which external tools and data sources Agentforce agents can access. A project management tool, an external knowledge base, a communication platform. All connected through MCP, all configured declaratively.

This maps directly to the thesis. MCP turns "what can engineering build?" into "what does the business need connected?" That's a fundamentally different question, and it puts decisions in the hands of the people closest to the business problem.

From what we've seen with clients, this shift accelerates Agentforce adoption significantly. When connecting a new data source doesn't require a sprint of custom development, teams start identifying connection opportunities they never would have raised before. The backlog of "things we wish the agent could access" starts shrinking.

The composable architecture angle matters here too. MCP gives Agentforce a standardized way to interact across the broader tech stack without point-to-point custom integrations. Each new connector follows the same pattern, which means each one is easier to configure, govern, and maintain than the last.

This extends beyond connecting agents to data sources. MCP is increasingly the protocol agents use to communicate with each other. In Agentforce, a service agent can delegate a billing question to a specialized billing agent, which then queries an external payment system, all through MCP connections. Instead of building one monolithic agent that tries to do everything, organizations can (and should) build networks of specialized agents that collaborate through governed channels. The protocol becomes the shared language of an entire agent ecosystem, not just the bridge between an agent and a database.

Start With the Business Problem, Not the Protocol

If this framing resonates, here's a practical starting point. Identify where your non-technical teams are manually feeding context to AI tools. Where are people copy-pasting data into prompts? Where are they uploading spreadsheets to get answers from ChatGPT? Those are your MCP candidates.

Start with one workflow, one connector, one team. See what governed AI context access looks like in practice before scaling. The organizations that get the most from MCP are the ones that pick a well-defined use case and deploy it before trying to connect everything.

Worth noting the preconditions. You need someone (an admin, an architect, an ops lead) who can configure connectors. And you need clarity on what data each role should access. The governance question comes before the technology question.

Worth being honest about the cost side, too. As organizations move beyond one or two connectors, the operational complexity compounds quickly. Each MCP server requires configuration, security review, ongoing monitoring, and maintenance as underlying systems change. Orchestrating multiple connectors across an enterprise tech stack isn't just a technical challenge; it's a governance and budget conversation that catches many organizations off guard. Getting the architecture right from the start, designing connector patterns that scale without spiraling maintenance costs, is where experienced partners make the difference between an MCP investment that compounds value and one that compounds overhead.

Where MCP Actually Matters

MCP's developer story is real, but it's the sideshow. The main event is giving every team in the organization safe, structured access to the context their AI tools need. That's not a development problem. It's an operations problem, a governance problem, and increasingly a competitive advantage for the organizations that figure it out first.