various mcp servers

How fast the ecosystem grew and what that pace implies

At launch in November 2024, roughly 100 MCP servers existed. By May 2025, that number had crossed 4,000. Public directories like MCP.so and Glama.ai now catalog over 21,000, and those figures exclude internal enterprise deployments entirely.

Download velocity tells the same story in starker terms. Under 100,000 downloads in November 2024. Eight million by April 2025. Sixty-seven million local server downloads projected for April 2026. That is not incremental growth; it is exponential in the literal, mathematical sense.

Here is the comparison that stopped me cold when I first saw it: MCP reached 1,400 servers in roughly one year. Zapier took five years to reach 1,400 integrations. The difference is barrier to entry. One developer, one afternoon, no platform approval process. The three-primitive model, tools, resources, and prompts, is constrained enough that a narrow, purpose-built server can be functional quickly.

Narrow is actually the operative word. The average MCP server exposes 13.4 tools; the median is 5. These are not monolithic connectors. They do one thing, or a tight cluster of related things. That granularity is a design feature, not a sign of immaturity in the ecosystem.

The vendor adoption picture has clarified considerably. OpenAI adopted MCP in March 2025. Google added native support in Gemini 2.5. Microsoft integrated it into Copilot Studio. Gartner projects 30% of enterprise application vendors will launch their own MCP servers in 2026. The supply side is accelerating even as many enterprise teams are still trying to understand what they already have running.

This growth curve is the terrain. The categories below are the map.

Developer tools and code: the category that bootstrapped the ecosystem

Developer tooling is where MCP found its first serious wave of production use, and the patterns established here became the template for every category that followed.

The GitHub MCP server, released as an official Anthropic reference implementation, covers repository search, issue management, pull requests, and code context. It gives agents the ability to act on a codebase through natural language rather than through a human intermediary. Context7 solves a specific and frustratingly common failure mode: agent hallucination on library versions. It injects up-to-date, version-specific documentation directly into the prompt at query time, so the agent reasons from current source material rather than training-data residue. Framelink's Figma MCP connects design data to coding agents like Cursor, enabling design-to-code conversion. That last example matters because it shows how MCP can extend the development workflow upstream, past the code editor, into the design phase itself.

There is a caution worth naming explicitly. The GitHub MCP reference server, along with the original GitLab, Google Drive, PostgreSQL, and Slack servers from Anthropic's initial release, moved to a servers-archived repository in 2025 and 2026 with no ongoing security guarantees. They continue to appear, frequently and without any archived flag, in tutorials and aggregator listings. The most-cited servers in developer documentation are not necessarily the best-maintained ones. Verifying against the current repository before deployment is essential due diligence; it is the minimum responsible step.

Cloud and infrastructure: when MCP servers become the interface to live production systems

In May 2025, AWS announced MCP servers for Lambda, ECS, EKS, and Finch. The framing from AWS was specific: equipping AI code assistants with real-time, contextual understanding of live cloud services, not just documentation. Microsoft released an Azure MCP server enabling natural language commands against Azure resources, and embedded MCP support into Copilot Studio.

The shift this category represents is qualitative, not just quantitative. Earlier MCP use cases involved agents reading external data. Cloud infrastructure MCP servers let agents issue commands that change infrastructure state. A filesystem MCP server exposes files. A cloud infrastructure server can provision, modify, or terminate resources. AWS alone spans multiple service namespaces through a single MCP interface, and without a formal tool inventory, the full surface of that interface is not always obvious to the teams deploying it.

A Zuplo survey of nearly 100 technical leaders in early 2026 found 72% expect their MCP use to increase in the next 12 months, with infrastructure servers as a primary growth vector.

This is the category where the question "what exactly can this server do?" becomes most consequential. The absence of a formal server registry creates the sharpest operational exposure here, because the cost of a misconfigured or compromised server is highest when that server can alter production systems.

Database servers: giving agents read and write access to structured data

According to Zuplo's 2026 survey, 63% of MCP users use MCP to sync with data sources such as documentation and knowledge bases. Database servers are, by that measure, the most common entry point for enterprise data integration.

The Supabase MCP server covers database management, authentication, storage, edge functions, and SQL workflows. MongoDB's MCP server exposes schema inspection and query execution to LLMs, meaning agents can interrogate collection structure before querying, which improves accuracy in practice rather than just in theory.

The capability that distinguishes this category from simple data retrieval is write access. Depending on permissions, agents are not just reading records; they can execute queries, write records, and modify data. The functional difference between read-only and read-write access is not consistently explicit in server documentation. You cannot assume from category alone what operations a given database server exposes; you have to check the tool list.

Authentication is where this gets uncomfortable. Astrix's analysis of over 5,200 open-source MCP implementations found that 53% rely on insecure, long-lived static secrets such as API keys and personal access tokens. OAuth adoption stood at just 8.5%. Database servers holding production data are particularly exposed when the authentication mechanism is a static credential living in a configuration file. That is the current state of a majority of open-source implementations, not a future risk.

Browser automation servers: agents that operate the open web

What distinguishes this category architecturally is that there is no fixed API surface. Instead of connecting to a specific service with a defined set of operations, browser automation servers give agents control of a live browser session: navigating, clicking, screenshotting, extracting content. The surface is not a tool list. The surface is the internet.

Playwright MCP, an official server, covers browser automation, page inspection, screenshots, and web interaction. The Chrome DevTools MCP, also official, controls and inspects a live Chrome browser from coding agents including Gemini, Claude, Cursor, and Copilot.

The use cases are intentionally broad: web scraping, form submission, UI testing, extracting information from sites without APIs. Anything a person can do in a browser, an agent with one of these servers can attempt.

That raises a question worth sitting with carefully. Unlike a database MCP server whose tool list is fixed and enumerable, a browser automation server's reach is defined by what the internet contains and what the agent is instructed to do. The agent's instructions matter as much as the server's capabilities, and probably more. For organizations thinking about policy alongside tooling, this is the category where those two conversations become inseparable, because the policy question cannot be answered by reading the server documentation alone.

Productivity and communication servers: connecting agents to the operational layer of the enterprise

This category covers the SaaS layer most enterprises already run on: project management, communication, payments, documentation. The operational connective tissue of organizational work.

The Atlassian MCP server, built officially, connects agents to Jira, Confluence, and Opsgenie. Agents can read tickets, update issues, query documentation stores. Stripe built their own MCP server covering payment, invoicing, customer, and subscription data. Slack's MCP server, one of the most actively used community implementations, provides message and channel access.

The pattern worth noting is first-party construction. Stripe building their own MCP server is a meaningful signal about how major vendors are repositioning. Salesforce reportedly routing 4.5 million MCP calls through its systems in late May 2026 suggests these companies are treating MCP as a product feature, not a community experiment. Of roughly 9,000 companies in the Zapier marketplace, 188 already have an MCP server, including Stripe, Amplitude, PagerDuty, Webflow, and Pipedrive.

The organizational implication follows directly from that shift. When a vendor ships their own MCP server, the question of what it exposes and to whom becomes a procurement and access-control question. It is no longer a decision a single developer makes on a Friday afternoon. It is a vendor relationship with an expanded capability surface, and security and access governance need to be present for that conversation, not brought in afterward.

Creative and specialized servers: the expanding frontier beyond enterprise defaults

In April 2026, Anthropic released nine creative tool connectors covering Blender, Adobe Creative Cloud across 50-plus tools, Autodesk, Ableton for music production, and Splice. UnityMCP offers real-time state monitoring and remote command execution inside a game engine's edit mode. Ghidra MCP exposes the Ghidra reverse-engineering platform's functionality to LLMs, enabling agents to autonomously analyze binary applications. That last one is a legitimate security research tool with obvious dual-use potential, and it appears here precisely because it illustrates that the MCP taxonomy includes tools requiring careful handling by people who actually understand what they are deploying.

What this category collectively illustrates is that MCP's three-primitive model is generic enough to wrap almost any software interface. The abstraction does not know or care what it is abstracting. That openness is the protocol's greatest strength and its most underappreciated governance challenge, and those two things are not separable.

For organizations mapping their MCP exposure, specialized servers present a particular difficulty. They are likely to enter the environment through individual practitioners: a 3D artist, a security researcher, a music producer with an agent-assisted workflow. The same low barrier to entry that drove the ecosystem's overall growth applies here. IT procurement does not see these servers coming; they arrive through individual practice, often quietly, often without any formal authorization process.

How transport and hosting choices change what a server can do and how it's managed

Local stdio deployment runs as a subprocess on the user's machine, scoped physically to that machine. This was the dominant model in MCP's first wave and remains common in developer-tool use cases. Remote streamable HTTP deployment runs as a network-accessible service, meaning any authorized client can connect and shared enterprise deployments become possible.

As of October 2025, 80% of the most-searched MCP servers offered remote deployment. Remote is already the majority mode for widely-used servers. And 93% of servers have migrated to Streamable HTTP, the current transport standard, versus 7% still on the deprecated SSE transport. The ecosystem follows spec changes quickly when the major SDKs adopt them as defaults. Figma, Cloudflare, and Vercel were among the early adopters of the remote server model, a pattern that signals movement from individual developer tools toward platform-level infrastructure.

The management implication is significant and often glossed over. A local stdio server is scoped to one user's session. A remote MCP server is shared infrastructure, and it requires the same governance treatment as any other internal API: authentication, access control, audit logging. Those are not optional features. They are the minimum requirements for running something on a network.

Authentication tells a generational story. Of 56 production servers analyzed in a May 2026 snapshot, approximately 21 use OAuth 2.1 as the primary authentication method; roughly 17 use API keys; connection strings and personal access tokens account for the rest. Vendor-hosted servers shipping in 2026 default to OAuth 2.1. Community stdio servers from 2024 and 2025 default to static credentials. The ecosystem is improving, but not uniformly, and the gap between a well-secured remote server and a poorly-secured one is not a matter of degree; it is a matter of kind.

What the full map of server types means for organizations deploying agents deliberately

The categories are not interchangeable in risk or scope. A documentation-sync server and a cloud infrastructure server both carry the label "MCP server," but their operational profiles differ as much as a read-only report differs from a production API with write access. Treating them as equivalent because they share a protocol is the kind of category error that produces real incidents.

Zuplo's 2026 survey found that most MCP users already have between 2 and 7 servers configured. Organizations are running multi-server environments, often without a complete inventory of what each server actually exposes. That is not a projected risk; it is the current operational state of many teams that adopted agentic tooling quickly and audited it slowly, if at all.

The taxonomy this piece has worked through is the beginning of a deliberate deployment posture, not the conclusion. For each server in an environment, the questions that follow from the map are: What category does this server belong to, and what is its actual tool surface? Is it local or remote, and what authentication method does it use? Is it maintained by the vendor, the community, or an archived repository? Who authorized it, and does that authorization reflect a genuine understanding of what the server can actually do?

Most organizations are already inside the MCP ecosystem before they have fully decided to be. The growth curve is not slowing; if anything, Gartner's 2026 vendor adoption projection suggests the supply side is accelerating. The question is no longer whether to engage with MCP servers. It is whether the engagement is intentional, and that starts with knowing what you are actually looking at.