Positioning a Developer Tool for MCP

Server downloads grew from roughly 100,000 in November 2024 to over 8 million by April 2025. By December 2025, Anthropic reported over 97 million monthly SDK downloads across all languages. React took approximately three years to reach 100 million monthly npm downloads. MCP got there in 16 months.

The number matters less as a health signal and more for what it implies about positioning. At this velocity, first-mover claims erode faster than most teams anticipate. The ecosystem is already segmented into over 1,200 developer-tools servers and over 950 business-application servers. Those aren't just different product categories; they're different buyer profiles with genuinely different pain hierarchies. A tool that speaks to "all MCP users" is, in practice, speaking to no one.

Gartner projects that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025. MCP is the connective tissue for that buildout. The window for category-defining claims is compressing, not expanding, which means the interesting strategic question isn't whether to position, it's whether you're late.

There's a transport signal worth watching too. A December 2025 survey by Zuplo found that 59% of MCP builders now use Streamable HTTP versus 34% on stdio. Tools built for stdio-only workflows are already trailing the direction of the field. Which transport your tool targets tells buyers something about which half of the market you actually understand.

The structural gap the ecosystem's own growth created: most MCP adoption is still pre-production

Per Clutch Security's 2026 report, 86% of MCP servers run locally on developer machines. Only 5% run in production environments. Most of those 97 million monthly SDK downloads are experimental, not operational. The ecosystem built a massive on-ramp and almost nobody has merged onto the highway yet.

Zuplo's survey data is consistent. Fifty percent of MCP server builders named security and access control as their top challenge. Thirty-eight percent said security concerns were the main blocker to broader adoption. Twenty-four percent of surveyed servers run with no authentication at all. Docker's State of Agentic AI survey, drawing on more than 800 developers, found 46% of teams naming security and compliance the top MCP challenge, with 40% citing it as the primary blocker to building agents.

Stacklok's 2026 software report offers a useful counterpoint: 41% of surveyed software organizations already run MCP servers in limited or broad production. Small as a percentage, but meaningful as a buyer segment. These are organizations with the sharpest pain and the most immediate budget to solve it. They've moved past curiosity.

The gap between widespread experimentation and thin production deployment isn't a temporary awkward phase. It's a structural condition, and it's the clearest signal about where positioning should aim. Not at protocol education. Not at developer curiosity. At the specific friction that keeps projects from shipping.

Why the protocol's standardization changes the nature of ecosystem competition

In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded with Block and OpenAI. AWS, Google, Microsoft, Cloudflare, and Bloomberg joined as platinum members. This puts MCP on the same institutional trajectory as Kubernetes, PyTorch, and Node.js: vendor-neutral infrastructure the whole ecosystem builds on top of, not around.

The major platform adoptions followed quickly. OpenAI officially adopted MCP in March 2025, integrated across ChatGPT desktop. Microsoft released native MCP support in Copilot Studio in May 2025. Google AI Studio and Vertex AI both offer MCP integration through the Google AI Agent framework. The "our AI supports MCP, theirs doesn't" differentiation window has closed. The protocol is not a moat. It is a floor.

The spec is also actively evolving. MCP's 2026-07-28 version moves the protocol to stateless at the protocol layer, with a 12-month deprecation window for legacy versions. Tools that aren't tracking spec changes accumulate maintenance debt for every team depending on them.

When a protocol becomes commoditized infrastructure, differentiation has to live one layer up: in what a tool does with the protocol, not in whether it supports it. Leading with "MCP-native" as a distinguishing claim is table stakes messaging at this point.

The three natural positioning axes the protocol's own structure exposes

MCP defines its primitives precisely: Tools, which are actions an AI can invoke; Resources, which are data the AI can read; and Prompts, which are reusable templates the server exposes to the client. These aren't arbitrary design choices. They map directly onto the axes a developer tool can legitimately own.

Axis 1: Primitive depth

Which primitive does your tool make dramatically better to work with? A tool that makes Resource management, covering data access, schema mapping, and read controls, substantially easier than building raw MCP has a concrete and defensible claim. So does one that makes Tool definition and versioning less brittle across spec cycles. The specificity is the differentiator. Claiming all three primitives is, functionally, claiming none of them.

Axis 2: Integration pattern

The transport shift toward Streamable HTTP is a segmentation signal, not just a technical preference. Stdio-first tools already read as legacy to the 59% of the market that has moved on. HTTP-native tools read as current. Buyers notice this even when they don't articulate it as a transport question.

Axis 3: Workflow friction point

The 49% of MCP users who cite developer productivity as their primary ROI, per Zuplo's survey, are buying time saved. The real positioning question is which specific task they no longer have to do. Debugging, auth, schema generation, registry management, observability: each is a discrete wedge, each pointing to a different buyer with a different urgency level.

Tools that try to claim all three axes simultaneously produce positioning that sounds like a feature list. Developer tooling already has the highest server concentration, over 1,200, which means "we help developers build MCP servers" is the most crowded claim in the ecosystem. Tools in that space need Axis 3 specificity to cut through. Business application server builders represent a second-wave buyer whose friction sits closer to governance and access control than to build-time productivity. These are genuinely different markets, and the messaging that works for one will actively repel the other.

What real enterprise deployments reveal about which problems are worth owning

Block, formerly Square, runs over 60 internal MCP servers, integrated with Snowflake, Jira, Slack, Google Drive, and internal APIs. Thousands of employees use their AI assistant "Goose," and the company has reported cutting up to 75% of time on daily engineering tasks. What the deployment actually reveals is the management problem underneath it: at scale, the friction isn't connecting one server, it's managing dozens of them consistently. The identity, access, and routing challenges Block's team had to solve across 60-plus servers are the same friction an external governance tool can credibly position around.

Bloomberg's teams described the missing layer as "the missing middleware layer that includes systems for authentication, authorization, rate limiting, metering, and AI guardrails." Bloomberg built this internally because no external tool provided it at enterprise standard. They also transformed deployment cycles from days to minutes after implementing MCP infrastructure. That compression doesn't come from the protocol alone; it comes from solving the middleware problem the protocol deliberately deferred to the builder.

A McKinsey 2025 benchmark found that companies integrating AI systems with structured enterprise data and tool APIs see productivity improvements of 20 to 40% in targeted workflows, versus 5 to 15% for organizations using AI in isolation. Enterprise buyers have internal justification to pay for tools that help them hit those numbers, which means they're not shopping for protocol support. They're shopping for outcomes.

Every large-scale deployment shows the same pattern: auth, access control, observability, and registry management all had to be built on top of the protocol because the protocol didn't provide them. These are the production requirements the spec deferred, and they are the requirements a developer tool can own without competing against the spec itself.

How the governance and security layer became the fastest-growing positioning surface in the ecosystem

The security and governance segment carries the highest projected growth rate of any segment in the MCP ecosystem, with SNS Insider data pointing toward a substantial CAGR during 2026 to 2035, in a market projected to reach tens of billions of dollars by that point. Integration platforms dominate current share in 2025, but governance is where the trajectory is steepest. Current market share and growth rate are two different things, and confusing them is an easy mistake to make.

The BFSI sector, financial services and insurance, is the fastest-growing end-user segment according to SNS Insider. Financial services buyers carry strict compliance requirements and strong budget incentive to solve governance before deploying at scale. Developer tools with a governance angle have a natural enterprise wedge here; BFSI buyers move quickly when the regulatory exposure is visible and the pain is acute, which the Zuplo and Docker survey data suggest describes MCP production deployments at this moment.

Hybrid deployment is the fastest-growing deployment pattern. Tools that solve governance only for cloud-native or only for on-premises miss the fastest-growing buyer configuration entirely.

MCP Manager, built by Usercentrics, positions on this layer: a gateway, access controls, and real-time observability for MCP server deployments, aimed at production governance rather than build-time productivity. The positioning is coherent with where the market data points. It claims the underserved side of the adoption curve rather than the crowded side.

"We help you build MCP servers" is a crowded claim in a maturing space. "We help you run them safely in production" is a claim the market data indicates is underserved. Those two sentences are pointed at different buyers, and only one of them has room to move.

The specific positioning mistakes that are easy to make in a fast-moving ecosystem

The mistakes that compound fastest aren't obvious errors. They're plausible choices that feel defensible at the time and only reveal themselves as wrong when the market matures around them.

Claiming the protocol instead of a problem is the most common. "MCP-native" or "built for MCP" is true of every tool in the ecosystem. It's category membership, not a position.

Positioning against the spec instead of against the friction is a close second. The protocol is evolving; the 2026-07-28 spec is stateless at the protocol layer with a deprecation window. Tools that position around protocol features rather than workflow problems are forced to reposition every spec cycle. Workflow problems are stickier than protocol versions.

Speaking to the wrong adoption wave is a target market decision disguised as a messaging problem. Developer tools and business application servers have different buyers with different pain hierarchies. Messaging that splits the difference reaches neither, and you can't write your way out of that.

Conflating local adoption with production adoption is subtler. The 86% local versus 5% production gap, per Clutch Security's 2026 report, means most developers have "used MCP" but haven't yet confronted the production pain. A tool pitched at their current state has a fundamentally different message than one pitched at their next state. Pitching to where buyers are rather than where they're going has a short shelf life in a market moving this fast.

Building positioning around a transport assumption that's already shifting is easier to do than it sounds. Fifty-nine percent on Streamable HTTP, 34% on stdio, per Zuplo's December 2025 survey. Tools that don't address where the transport is going read as if they're solving yesterday's stack, which matters to a buyer choosing something they'll depend on for two or three years.

Treating security as a feature rather than a position is probably the most expensive mistake on this list. Fifty percent of builders name it their top challenge, and 38% say it's their primary blocker, per Zuplo's survey. That's a buyer pain point strong enough to anchor an entire product's positioning around, and treating it as a checkbox on a feature comparison page wastes the most urgent signal in the ecosystem.

Every mistake here shares the same root cause: trying to stay relevant to all of MCP's momentum rather than owning a specific piece of it. The tools that will define this ecosystem's next phase are the ones that pick a problem precise enough to be undeniable, and hold it while the protocol matures around them.