97 Million Downloads Later, MCP Isn't a Bet Anymore. It's Plumbing.

Ninety-seven million.

That's the number of monthly SDK downloads MCP hit in July 2026. Not cumulative. Not lifetime. Monthly. The npm SDK alone pulls roughly 156 million downloads per month. PyPI's mcp package sits around 271 million monthly. Combined, that's over 427 million downloads per month across two package registries, with the npm number representing the developer-facing tooling and the Python number representing the server-side and SDK implementations.

Sixteen months ago, when Anthropic open-sourced the Model Context Protocol in November 2024, it had 2 million monthly downloads. That number was treated as interesting but unproven. A bet by one company on how AI agents should connect to tools. Smart people disagreed about whether it would survive, let alone become the default.

It did. And the speed at which it happened has no clean precedent in the history of open protocols.

React took roughly three years to reach comparable npm download velocity after its initial release. gRPC took about seven years to reach similar adoption breadth across languages and ecosystems. GraphQL Federation took approximately four years to reach the kind of ecosystem saturation MCP achieved in a single quarter.

MCP did it in 17 months.

This article covers what that number means, why it happened, what it changes for teams building AI agents, and where the real risks still live. Because protocols don't go from 2 million to 427 million monthly downloads without something structural shifting. And structural shifts come with structural risks.

The Journey from 2 Million to 427 Million

The trajectory is worth tracing in detail because the growth curve tells you something that raw numbers don't.

Phase 1: The Quiet Launch (November 2024 - March 2025)

Anthropic open-sourced MCP on November 25, 2024. The initial release was clean but modest: a specification for how AI models connect to tools, data sources, and external systems. The SDK supported TypeScript and Python. The documentation was thorough. The reception was polite.

At launch, MCP had roughly 2 million monthly downloads across npm and PyPI. The developer community treated it as an interesting Anthropic project, not an industry standard. Fair enough. Most open-source protocols launched by a single company stay that way.

What made MCP different, in retrospect, was the architectural bet it made. Instead of designing a protocol that optimized for any single use case, MCP designed for the specific problem that every AI agent team was independently solving: how do you let a model discover and invoke tools without hardcoding every connection?

The problem was universal. Every team building agents was writing custom tool integration code. Every team was managing API keys in environment variables. Every team was building the same thin middleware layer between their LLM and the outside world. MCP offered a standard way to do that plumbing.

Phase 2: The Adoption Inflection (March 2025 - September 2025)

The inflection point came when the major AI coding tools started shipping native MCP support. Cursor added MCP integration. Claude Desktop made MCP its tool connection layer. VS Code's agent mode adopted MCP for tool access. Each integration was a distribution event, putting MCP into the hands of developers who hadn't explicitly chosen to adopt it.

By September 2025, monthly downloads had grown to approximately 12 million. That's a 6x increase in 10 months. The registry tracked over 2,000 public MCP servers covering everything from database access to web search to file system operations.

The growth wasn't just quantitative. The quality of MCP servers improved dramatically. Early servers were mostly demos. By mid-2025, production-grade servers appeared for major cloud services, SaaS platforms, and development tools. Block published several of their internal MCP servers. Cloudflare released MCP servers for their edge computing platform. The ecosystem was building on itself.

Phase 3: The Governance Catalyst (October 2025 - December 2025)

Two events in late 2025 transformed MCP from "popular protocol" to "industry infrastructure."

First, the co-founding of MCP's governance expanded beyond Anthropic. Block and OpenAI joined as co-founders, with AWS, Google, Microsoft, Bloomberg, and Cloudflare signing on as Platinum members. This wasn't ceremonial. It meant that the companies building the largest AI platforms in the world had committed to MCP as their tool connection standard.

Second, on December 9, 2025, Anthropic donated MCP to the Linux Foundation under the AAIF (AI Alliance Initiative Foundation) governance model. This was the moment that changed the enterprise procurement conversation entirely.

Phase 4: The Enterprise Flood (January 2026 - Present)

The Linux Foundation governance combined with multi-vendor backing unlocked enterprise adoption that had been held back by single-vendor risk concerns. By January 2026, monthly downloads crossed 40 million. By April, they hit 65 million. By July, the combined npm and PyPI downloads reached 427 million monthly.

The registry now tracks 24,867 public MCP servers. Of those, approximately 80% are actively maintained. The top 0.1% of MCP packages (roughly 25 packages) account for 84% of total installs, following a power-law distribution typical of infrastructure-level tools. The long tail of specialized servers exists but the core infrastructure is concentrated in a small number of well-maintained packages.

The download numbers deserve context. npm downloads include CI/CD pipelines, container builds, and automated installs that may not represent unique developer adoption. But the growth rate is the signal. A 48x increase in monthly downloads in 16 months, across a protocol category that typically grows linearly, indicates something structural. MCP didn't just gain popularity. It became the default assumption.

What MCP Actually Does (And What It Doesn't)

Before going further into the adoption story, it's worth being precise about what MCP is and isn't, because the terminology gets loose in casual conversation.

The Core Concept

MCP is a protocol specification. It defines a standard way for AI models to discover, understand, and invoke external tools, data sources, and services. It operates on a client-server model:

• MCP Hosts are the AI applications that need tool access: ChatGPT, Cursor, Claude Desktop, VS Code's agent mode, or any custom agent application.
• MCP Clients are the libraries within those hosts that speak the MCP protocol. They handle connection management, tool discovery, and request/response formatting.
• MCP Servers are the tool providers. A web search server exposes a search tool. A database server exposes query and list_tables tools. A file system server exposes read_file and write_file tools.

The protocol defines two core interactions: tools/list (what tools are available?) and tools/call (invoke this tool with these arguments). That's the specification's core. Everything else is implementation detail.

The Transport Layer

MCP originally supported two transports: stdio (for local process communication) and SSE (Server-Sent Events, for HTTP-based communication). In early 2026, the specification added Streamable HTTP as the recommended transport, and the ecosystem has rapidly converged on it.

By July 2026, 93% of new MCP deployments use Streamable HTTP transport. The shift is significant because Streamable HTTP enables remote tool access, stateless deployments, load balancing, and CDN caching — all the infrastructure patterns that teams need for production-grade agent systems. Stdio works for local development. Streamable HTTP works for production.

What MCP Is Not

MCP is not an AI model. It doesn't make decisions, generate content, or reason about problems. It's a protocol layer that connects models to tools.

MCP is not a replacement for APIs. MCP servers typically wrap existing APIs. A Salesforce MCP server doesn't replace the Salesforce API — it provides a standardized way for AI models to discover and invoke Salesforce operations through that API.

MCP is not an orchestration framework. It doesn't manage multi-agent workflows or handle agent-to-agent communication. Those concerns sit above the protocol layer.

MCP is also not inherently secure. The protocol defines how tools are discovered and invoked, but authentication, authorization, and rate limiting are implementation concerns that individual MCP servers must address.

The Streamable HTTP Shift

The move from SSE to Streamable HTTP is the technical story behind the adoption surge. SSE required persistent connections between client and server — no connection pooling, no load balancing, no HTTP caching, and friction with enterprise firewalls. Streamable HTTP makes each tools/call a stateless HTTP request that can be load-balanced, cached, and routed like any other API call.

This turned MCP from a developer tool into an infrastructure protocol. Once you can deploy MCP servers behind a load balancer and manage them with standard HTTP tooling, the deployment complexity drops dramatically. The adoption surge from January to July 2026 correlates directly with production teams discovering that Streamable HTTP made MCP deployment tractable.

Why MCP Won the Protocol War

MCP wasn't the only protocol competing to be the standard tool connection layer for AI agents. OpenAI pushed their own function calling format. Google had their tool use specification. LangChain had its own tool abstraction. Several smaller protocols attempted to fill the same niche.

MCP won. The reasons are instructive for anyone building infrastructure in the AI space.

Reason 1: Neutral Governance

The single most important factor was governance. When MCP was Anthropic's protocol, OpenAI and Google had rational reasons not to adopt it. Supporting your competitor's standard creates dependency. But once MCP moved to the Linux Foundation with Anthropic, Block, and OpenAI as co-founders, and AWS, Google, Microsoft, Bloomberg, and Cloudflare as Platinum members, the competitive dynamic dissolved.

No company "owns" MCP. The Linux Foundation manages it the same way it manages Linux, Kubernetes, and hundreds of other foundational open-source projects. Enterprise procurement teams understand this governance model. A single-vendor protocol is a risk. A Linux Foundation-governed protocol is infrastructure.

Reason 2: Solving a Real Problem

MCP solved a problem that every team building AI agents had. Before MCP, integrating a new tool into an agent required writing custom integration code, managing authentication separately, and handling discovery manually. With MCP, tool providers publish MCP servers and agent developers consume them through a standard interface.

The problem was universal enough that adoption was organic. Teams didn't need to be convinced that a standard tool connection layer was useful. They needed to be convinced that MCP was the right standard. Once the governance concerns were addressed, the adoption was a matter of implementation convenience.

Reason 3: Network Effects and the Registry

The MCP server registry created a self-reinforcing cycle. More MCP servers made the protocol more useful. More usefulness drove more adoption. More adoption encouraged more server development. The registry hit 10,000 active servers by mid-2026 and 24,867 by July 2026.

The top 0.1% of MCP packages — the core infrastructure servers for web search, file systems, databases, and major SaaS platforms — handle 84% of installs. This concentration is typical of infrastructure protocols. Most teams use the same 10-20 core servers. The long tail exists for specialized use cases, but the protocol's value comes from the core set being reliably maintained.

Reason 4: Native Platform Support

The tipping point was when major AI platforms shipped native MCP support, not just compatibility. ChatGPT, Cursor, Gemini, Copilot, and VS Code all support MCP natively. This means that millions of developers who use these tools are already MCP-connected without having made an explicit adoption decision.

When your IDE speaks MCP by default, when ChatGPT can call MCP tools out of the box, when your cloud provider's agent platform routes through MCP — the protocol stops being a choice and starts being plumbing. That's the transition that the download numbers reflect.

The Comparison: How Fast Is Fast?

To appreciate the speed, here's how MCP's adoption trajectory compares to other foundational protocols:

The comparison isn't perfectly apples-to-apples. MCP launched into a market with higher baseline demand (the AI agent boom) and benefited from embedding the protocol in popular tools from day one. React, gRPC, and GraphQL didn't have ChatGPT and Cursor as distribution channels.

But the speed matters because it sets expectations. When a protocol goes from 2 million to 427 million monthly downloads in 16 months, the ecosystem matures that fast too. The tooling, best practices, security patterns, and production deployment knowledge all develop on the same compressed timeline. Teams adopting MCP today aren't adopting an experimental protocol. They're adopting something with 17 months of production history and governance designed for long-term stability.

The Linux Foundation Moment

The December 9, 2025 donation to the Linux Foundation deserves deeper analysis because it fundamentally changed the protocol's trajectory.

What AAIF Governance Actually Means

AAIF (AI Alliance Initiative Foundation) is the Linux Foundation's governance framework for AI-related open-source projects. Under this model:

• Technical decisions are made by a Technical Steering Committee with representatives from contributing organizations. No single company has veto power.
• Commercial contributions are welcome under a Contributor License Agreement (CLA) that prevents any single entity from controlling the project's direction.
• The specification is developed openly, with public discussions, recorded decisions, and transparent evolution.
• Brand and trademark management follows established Linux Foundation practices, preventing fragmentation and fork confusion.

Why This Mattered for Enterprise

Before the Linux Foundation donation, MCP faced a common enterprise objection: "What happens if Anthropic changes the protocol in a way that disadvantages us?" This is the single-vendor risk that kills protocols in enterprise procurement. Every CIO has a graveyard of abandoned standards that depended on one company's continued goodwill.

The Linux Foundation governance eliminated this objection. MCP is now governed the same way as Linux (which runs most of the world's servers), Kubernetes (which runs most of the world's containers), and CNCF projects (which run most of the world's cloud infrastructure). Enterprise procurement teams understand Linux Foundation governance. It's a checkbox on the risk assessment form.

Block's participation was particularly significant. Block is not primarily an AI company. They adopted MCP to standardize how their 340+ internal tool connectors work with AI agents. After MCP adoption, Block retired those 340 proprietary connectors and replaced them with MCP servers. That's a $200B+ company betting their internal tool infrastructure on MCP, and they did it under Linux Foundation governance.

The Co-Founder Signal

The co-founding coalition tells you who considers MCP critical infrastructure:

• Anthropic: Created MCP, invested in its success
• Block: Retired 340 proprietary connectors for MCP
• OpenAI: Adopted MCP in ChatGPT and Codex despite initially competing with their own function calling format

The Platinum members tell you who's willing to invest resources in MCP's continued development:

• AWS: Integrated MCP into Bedrock AgentCore
• Google: Added MCP support to Gemini
• Microsoft: MCP support in VS Code and Copilot
• Bloomberg: Enterprise financial data through MCP
• Cloudflare: Edge computing and AI agent infrastructure via MCP

When these organizations co-found and fund a protocol under neutral governance, it stops being a bet. It's the same kind of infrastructure commitment that Linux, HTTP, and TCP/IP received in their respective adoption curves.

Real Enterprise Deployments

The download numbers and governance structure are important context. But what matters for teams building AI agents is what MCP looks like in production.

Block: The 340-Connector Retirement

Block's MCP adoption is the most visible enterprise case study. Before MCP, Block maintained 340 custom connectors for their internal tools. Each connector had its own authentication mechanism, its own error handling, its own documentation (sometimes), and its own maintenance burden.

After adopting MCP, Block retired all 340 connectors and replaced them with MCP servers. The practical benefits:

• Reduced maintenance: Instead of 340 custom integrations, Block maintains MCP servers that follow a standard interface. Changes to downstream APIs need to be fixed once in the MCP server, not in 340 individual consumers.
• Agent compatibility: Any AI agent that speaks MCP can now access Block's internal tools without custom integration. The same agent framework works across all tools.
• Governance clarity: Under Linux Foundation governance, Block has confidence that the protocol won't shift under them. This confidence enabled the full migration rather than a cautious pilot.

Enterprise Adoption Patterns

Beyond Block, enterprise adoption of MCP follows a recognizable pattern. According to industry data, 67% of enterprise AI teams are either actively using MCP or evaluating it for production use. The adoption pattern typically looks like:

1. Discovery: A team builds an AI agent that needs tool access. They discover MCP through their IDE (Cursor, VS Code) or their model provider (ChatGPT, Claude).
2. Pilot: The team builds a small number of MCP servers for their most commonly used tools. The standard interface reduces integration time compared to custom tool connections.
3. Expansion: Other teams in the organization adopt the same MCP servers. The standard interface means teams share tool implementations rather than duplicating them.
4. Governance: The organization formalizes MCP as their tool connection standard, typically citing the Linux Foundation governance as a key factor in the procurement decision.

What's Actually Running

The MCP server registry tells you what enterprises are building: database access servers (PostgreSQL, MySQL, MongoDB), cloud service servers (AWS, GCP, Azure), SaaS integration servers (Salesforce, Jira, Slack, Notion), development tool servers (GitHub, GitLab, CI/CD), and web/search servers. Each represents work that teams previously did manually. When an agent needs to check a Jira ticket, query a database, and post to Slack — three operations that previously required three custom integrations — MCP lets them do all three through a standard interface.

The Security Elephant in the Room

The growth numbers are impressive. The governance is solid. The enterprise adoption is real. But there's a security concern that the industry is still working through, and ignoring it would be dishonest.

The Shadow IT Problem

In mid-2026, Qualys published research flagging MCP servers as a "new Shadow IT" vector. The concern is straightforward: MCP servers can be deployed by individual developers or teams without central IT approval, creating unauthorized access paths to sensitive systems.

Consider the scenario: a developer sets up an MCP server that connects to a company's production database. The server runs on their local machine during development. It works great. They share it with a colleague. The colleague sets up their own copy. Soon, there are a dozen copies of the same MCP server running across the team, each with its own database credentials, each without centralized audit trails, each potentially accessible to anyone on the team's network.

This is Shadow IT. It's not new — developers have been creating unauthorized access paths since the first API key was pasted into a .env file. But MCP's ease of deployment makes it faster to create and harder to track than previous generations of Shadow IT.

The Specific Vulnerabilities

The research identified several concrete concerns: static secrets — API keys and database credentials stored in MCP server configuration files that don't rotate automatically; no built-in audit trails — the MCP protocol doesn't require logging which agent called which tool; unauthorized tool exposure — an MCP server exposing a database query tool gives any connected agent database access without scope controls; and transport security assumptions — not all MCP deployments use TLS, especially local development servers extended to shared environments.

What the Industry Is Doing About It

The security concerns are real, but they're being addressed. Linux Foundation governance provides a structure for security-focused evolution of the specification. Enterprise MCP server implementations are adding token-based authentication, rate limiting, scope restrictions, and audit logging. MCP server registries are adding security scanning. Agent frameworks are adding tool-level authorization, letting administrators define which agents can call which MCP servers with what scope.

The Pragmatic Response

For teams deploying MCP in production, the pragmatic approach is layered:

1. Treat MCP servers like APIs. Apply the same authentication, authorization, rate limiting, and monitoring you'd apply to any API endpoint.
2. Centralize MCP server deployment. Don't let individual developers deploy MCP servers that access production systems. Establish a registry of approved servers.
3. Implement tool-level scoping. An agent that needs read access shouldn't have write access. Configure minimum scope for each agent.
4. Enable audit logging. Every tools/call should be logged with agent identity, timestamp, tool name, parameters, and response status.
5. Rotate secrets. Automate credential rotation on a regular schedule.

The security concern is real, but it's not a reason to avoid MCP. It's a reason to deploy MCP responsibly. The same was true for Docker (container escape vulnerabilities), Kubernetes (RBAC misconfigurations), and every other infrastructure technology that moved from development to production. The security tooling catches up. It just takes time.

What to Build on MCP

With the adoption numbers, governance, and security landscape mapped, the practical question is: what should your team actually build with MCP?

The MCP-Native Agent Stack

A modern MCP-native agent architecture looks like this:

User Request
     │
     ▼
┌─────────────────┐
│  Agent Logic     │  LLM + orchestration
│  (reasoning +    │  (Claude, GPT, Gemini)
│   tool selection)│
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  MCP Client     │  Protocol layer
│  (discovery +   │  tools/list, tools/call
│   invocation)   │
└────────┬────────┘
         │
    ┌────┴────┬──────────┬───────────┐
    ▼         ▼          ▼           ▼
  Web       Database   SaaS        Custom
  Search    MCP        MCP         MCP
  MCP       Server     Servers     Server
  Server

The agent logic lives in the LLM and orchestration framework. The MCP client handles tool discovery and invocation. MCP servers provide the actual tool implementations. The layers are cleanly separated, which means you can swap the LLM, add new tools, or change tool implementations without affecting the other layers.

Where MCP Delivers the Most Value

Based on production deployments we've seen and worked on at MojoStudio, MCP delivers the most value in three scenarios:

Multi-tool agents. When an agent needs to interact with more than three external systems, the standard interface of MCP eliminates per-tool integration code. Instead of writing custom integration for each tool, you deploy MCP servers and the agent discovers them automatically.

Shared tool infrastructure. When multiple agents in an organization need access to the same tools, MCP servers become shared infrastructure. One well-built database MCP server serves every agent that needs database access. Without MCP, each agent team builds their own database integration.

Rapid prototyping. When you need to build a new agent quickly, the MCP ecosystem means you can compose existing tools instead of building from scratch. Need your agent to search the web, query a database, and post to Slack? There are MCP servers for all three. Wire them together and you have a working prototype in hours, not weeks.

Where MCP Is Less Useful

MCP isn't the right choice for every scenario:

Single-tool agents. If your agent interacts with one external system, the overhead of an MCP server is probably unnecessary. A direct API integration is simpler.

Real-time streaming. MCP's request-response model works well for tool calls that complete in seconds. For tools that stream data continuously (video feeds, real-time sensor data), you'll need a different approach.

Tightly coupled systems. If your agent and tool implementation are tightly coupled (same team, same codebase, same deployment), the abstraction layer of MCP adds complexity without proportional value. MCP shines when the agent developer and tool provider are different teams or organizations.

Building MCP Servers for Your Organization

If your organization has internal tools that AI agents need access to, building internal MCP servers is one of the highest-leverage infrastructure investments you can make. A single MCP server that exposes your internal CRM operations serves every AI agent in your organization that needs CRM access. Without MCP, each agent team builds their own integration. With MCP, you build it once and every agent consumes it through the standard interface.

The server doesn't need to be complex. It wraps your existing API, exposes operations as MCP tools, and handles authentication through whatever mechanism your system uses. The value isn't in complexity — it's in the standard interface that makes it composable.

The Indian Enterprise Angle

For Indian enterprises and startups, MCP adoption has specific implications worth examining.

The Scale of the Opportunity

India's IT services sector — TCS, Infosys, Wipro, HCLTech, and thousands of smaller firms — is the world's largest provider of software development and IT services. These companies build and maintain AI agents for clients globally. MCP's standardization of tool connections directly impacts their delivery model.

When an Indian IT services company builds an AI agent for a US bank, they need to connect that agent to the bank's CRM, database, ticketing system, and internal tools. Before MCP, each integration was custom work. With MCP, the integration work is reduced to deploying MCP servers for each tool.

This is a margin improvement story. The same revenue, delivered with less effort, which means either higher margins or more competitive pricing.

The Adoption Pattern in Indian Companies

Indian enterprise adoption of MCP follows a recognizable pattern:

Product companies adopt first. Indian SaaS companies like Freshworks, Zoho, and Postman were early MCP adopters because their products are tools that AI agents need to access. Making their products MCP-compatible is a competitive advantage.

IT services companies follow. Services companies adopt MCP when their clients require it. As global enterprises standardize on MCP, their Indian service providers need to deliver MCP-compatible solutions.

Enterprise IT teams are cautious. Indian enterprise IT teams adopt MCP more slowly, with the same governance, security, and procurement considerations that slow adoption globally. The Linux Foundation governance helps, but the timeline is measured in quarters, not weeks.

The Cost Equation

For Indian companies building on MCP, the cost dynamics are favorable. MCP servers are open-source and self-hosted, so infrastructure cost is limited to running the server, not per-call licensing fees. The more significant cost consideration is engineering time. Building production-grade MCP servers requires understanding the protocol specification, implementing proper authentication, and handling error cases correctly. The learning curve is measured in days to weeks, not months, and the investment pays back quickly through reduced integration work.

If you're evaluating how AI agent infrastructure fits into a broader product build, our breakdown of app development costs in India covers how agent features change project scope and budget.

MojoStudio's Take

We've been building on MCP since early 2025, first experimentally and then in production. Here's our honest assessment.

What We Got Right

Our early bet on MCP as the tool connection standard paid off. When we built our first production agent workflows — documented in our first Bedrock AgentCore deployment and AgentCore field notes — MCP was already the protocol layer underneath. The AgentCore Gateway is MCP-compliant, which meant our agent logic was portable across frameworks from day one.

The practical benefit is that we can swap agent frameworks without rewriting tool integrations. When we moved from a custom agent framework to LangChain for one project, and from LangChain to Strands SDK for another, the MCP tool layer stayed the same. The agent logic changed. The tools didn't.

What We'd Do Differently

We underestimated the security surface area. Our first MCP servers were built for speed — get the tool working, connect the agent, ship it. Authentication was basic, audit logging was minimal, and scope controls were coarse-grained. We tightened all of this in subsequent iterations, but the lesson is clear: build security into your MCP servers from day one.

We also underestimated tool description quality. MCP servers expose tools with descriptions that the LLM reads to decide whether and how to use them. Vague descriptions produce unreliable tool selection. We went through multiple iterations before our agent's tool selection stabilized. Budget time for this — it's prompt engineering at the tool description level.

What We Tell Clients

For teams evaluating MCP, our advice is straightforward:

Start with the core infrastructure servers. The registry's top 0.1% of packages cover 84% of common use cases. Web search, database access, file operations, and major SaaS integrations already have well-maintained MCP servers. Use them before building custom ones.

Build internal MCP servers for your most-used tools. If your team repeatedly connects agents to the same internal APIs, build an MCP server once and share it. The ROI is immediate.

Treat MCP servers like production services. They need authentication, authorization, monitoring, and documentation. The fact that they're open-source doesn't mean they're throwaway.

Monitor the security landscape. MCP security is evolving. The Qualys research is worth reading. The Linux Foundation governance is worth trusting. The practical security posture depends on how you deploy and manage your MCP servers, not on the protocol itself.

MCP went from 2 million to 427 million monthly downloads in 16 months. It's governed by the Linux Foundation. It's backed by every major AI platform company. It's deployed in production by enterprises from Block to Bloomberg.

The question is no longer whether MCP will be the standard tool connection layer for AI agents. That's settled. The question is how your team will build on it — securely, efficiently, and in a way that compounds the investment over time.

If you're building AI agent workflows and want to understand how MCP fits into your architecture, our engineering team has hands-on experience deploying MCP-based systems in production and can help you design the right approach for your use case.

Frequently Asked Questions

1. What is MCP and why is it important for AI agents?

MCP (Model Context Protocol) is an open protocol that standardizes how AI models discover and invoke external tools, data sources, and services. It defines a client-server architecture where MCP hosts (like ChatGPT, Cursor, or custom agents) communicate with MCP servers (tool providers) through a standard interface. MCP is important because every AI agent needs to interact with external systems, and before MCP, every team built custom integrations. MCP eliminates that duplication with a single standard that's now supported by every major AI platform.

2. How fast has MCP actually grown, and are the download numbers reliable?

MCP went from 2 million monthly SDK downloads at launch (November 2024) to 427 million combined monthly downloads (npm + PyPI) by July 2026. That's a 48x increase in 16 months. The download numbers include CI/CD pipelines and automated installs, so they overcount unique developers somewhat. But the growth rate is the reliable signal — a 48x increase in a protocol category that typically grows linearly indicates structural adoption, not just experimentation.

3. Who governs MCP, and does that matter for enterprise adoption?

MCP is governed by the Linux Foundation under the AAIF (AI Alliance Initiative Foundation) framework. Anthropic, Block, and OpenAI are co-founders. AWS, Google, Microsoft, Bloomberg, and Cloudflare are Platinum members. This governance matters because enterprise procurement teams need confidence that the protocol won't be controlled by a single vendor. Linux Foundation governance — the same model used for Linux, Kubernetes, and other foundational infrastructure — provides that confidence.

4. What is Streamable HTTP and why did it change MCP adoption?

Streamable HTTP is MCP's recommended transport protocol, replacing the original SSE (Server-Sent Events) transport. It makes MCP interactions stateless HTTP requests, enabling load balancing, caching, CDN deployment, and standard HTTP infrastructure patterns. By July 2026, 93% of new MCP deployments use Streamable HTTP. The shift was a key factor in the adoption surge because it made MCP deployment tractable for production teams who needed standard infrastructure patterns.

5. Is MCP secure enough for enterprise use?

The MCP protocol specification doesn't mandate security features like authentication, authorization, or audit logging — those are implementation concerns for individual MCP servers. This creates a security gap that the industry is actively addressing. Qualys flagged MCP servers as a "Shadow IT" risk in mid-2026. For enterprise use, MCP servers should be deployed with the same security rigor as APIs: authentication, scope restrictions, audit logging, and secret rotation. The Linux Foundation governance provides a structure for evolving the specification's security requirements.

6. How does MCP compare to OpenAI function calling or other tool protocols?

MCP is an open, vendor-neutral protocol governed by the Linux Foundation. OpenAI's function calling is a proprietary format specific to OpenAI models. Google has its own tool use specification. MCP's advantage is interoperability — an MCP server works with any MCP-compatible host (ChatGPT, Cursor, Claude, Copilot, custom agents). This means tool providers build one MCP server and it works everywhere, rather than building separate integrations for each AI platform.

7. What's in the MCP server registry, and how do I find the right servers?

The MCP server registry tracks 24,867 public servers as of July 2026, with approximately 80% actively maintained. The top 0.1% of packages (roughly 25 servers) handle 84% of installs and cover core infrastructure: web search, file systems, databases, major cloud services, and popular SaaS platforms. Start with the registry's featured or highest-installation servers for your use case. The registry provides maintenance status, contributor information, and documentation links for each server.

8. Should my Indian company adopt MCP for AI agent development?

If your company builds AI agents that need to connect to external tools, databases, or services, MCP is the standard to build on. The Linux Foundation governance addresses enterprise procurement concerns. The open-source nature means infrastructure costs are limited to running the servers, not licensing fees. Indian IT services companies benefit particularly because MCP standardizes tool integration, reducing the custom work required for each client engagement. For product companies, making your product MCP-compatible means AI agents can integrate with it more easily.

9. What are the main risks of building on MCP?

The primary risks are: (1) security — MCP servers must be deployed with proper authentication, authorization, and audit logging, which the base specification doesn't mandate; (2) ecosystem immaturity — while the core infrastructure servers are solid, specialized servers may have bugs or gaps; (3) governance evolution — the Linux Foundation governance is new, and the specification will evolve in ways that may require updates to your MCP servers; (4) vendor concentration in the registry — the top 0.1% of packages handle 84% of installs, meaning the ecosystem's core infrastructure depends on a small number of maintainers. All of these are manageable risks with proper engineering practices.

10. How do I get started building with MCP?

Start by using existing MCP servers rather than building your own. Pick an agent framework (LangChain, Strands SDK, or a custom implementation), connect it to an MCP host (like Cursor or Claude Desktop for development, or a custom agent for production), and configure it to use published MCP servers for your tool needs. For your own tools, build simple MCP servers that wrap your existing APIs. The protocol is straightforward — tools/list for discovery, tools/call for invocation. The investment is in tool description quality and security configuration, not in protocol complexity. For hands-on guidance, our engineering team can help you design the right MCP architecture for your use case.