The MCP Ecosystem Explained

The MCPModel Context Protocol, an open JSON-RPC standard that lets any AI client connect to any compliant server through a single, shared interface. spec itself is lean. The ecosystem around it is not. Thousands of servers now sit across GitHub, npm, PyPI, and dedicated registries. The list of clients that speak MCP keeps growing. Tooling for building your own servers is getting better by the month. If you want to know what is out there and how to reason about it, read on.

If you have not read the fundamentals yet, start with MCP Fundamentals first. This guide assumes you already know the host/client/server split.

Why one standard changes everything

Before MCP, every AI application that needed an external capability had to write its own connector. A new database tool meant new code in every app that wanted it. A new app meant rebuilding every integration from scratch. The cost scaled with M times N, where M is the number of apps and N is the number of tools.

MCP collapses that to M plus N. Each app learns the protocol once. Each server implements it once. They interoperate without knowing a thing about each other.

That shift is what created the ecosystem. Once a server speaks MCP, every compliant client can use it straight away. Authors who build servers get a free distribution channel to every MCP-capable host. That incentive is why you now have thousands of servers, covering everything from browser automation to financial data.

The three primitives, in practice

Every MCP server exposes some combination of three capability types. Understanding them tells you what a server can and cannot do before you install it.

Tools

Tools are callable functions. The model sees the tool name and its description, decides when to call it, and the server does the work. Tools are where side effects happen: writing a file, creating a pull request, running a search, inserting a database row.

Because tools can change state, they are the primitive worth scrutinising hardest before you add a server. A tool that writes files is fine. A tool that deletes files with no confirmation prompt is another matter.

Resources

Resources are read-only data the model can pull in as context. A resource might expose a file's contents, a database schema, a list of open tickets, or an API response. Nothing changes when a resource is read. The model uses the content to reason better, not to act.

Resources are the safe primitive. If a server only exposes resources, the worst it can do is feed the model stale or misleading information.

Prompts

Prompts are reusable, parameterised templates. A server can offer a "review this PR" prompt that accepts a repository and PR number, then assembles a detailed instruction set the host surfaces to the user as a slash command or a menu option.

You will interact with prompts most often through Claude Code's slash commands, where installed servers can register their own shortcuts. The MCP Configuration guide shows how to expose and invoke them.

How do clients connect to MCP servers?

The two transports are stdio and HTTP. Your choice decides where the server runs and how credentials flow. For a closer comparison of the trade-offs, see local vs remote MCP servers.

stdio · the client launches the server as a local subprocess and speaks to it over standard input and output. No network. This is the default for local tools like a filesystem server or a local SQLite browser. The server process lives only as long as the client session.

Streamable HTTP · the server runs somewhere on the internet and the client reaches it over HTTP. Credentials travel as headers, often with OAuthA delegated-access standard that lets you grant a service limited permissions to act on your behalf without handing over your password.. This is how hosted, multi-user servers work. GitHub's hosted MCP endpoint and remote database servers use this transport.

You may still see SSE listed in older documentation. It is deprecated. New servers use Streamable HTTP.Common gotchaDo not copy an SSE transport line from an old tutorial into a fresh setup.Newer clients may reject or silently fail to connect over SSE, and you will burn time debugging a config that was never going to work. Use the Streamable HTTP endpoint the server documents today.

A map of the server landscape

The community has built servers for most of the surfaces a developer touches day to day. Here is a category map with a few representative examples.

Treat the table as a snapshot. Browser automation and observability are moving fastest right now, and new entries land most weeks.

Where can I find MCP servers?

No single registry is authoritative, but a handful of sources are worth bookmarking. If you would rather start from a shortlist, the useful MCP servers guide walks through the ones worth wiring up first.

GitHub MCP Registry · the closest thing to an official index. As of mid-2026 it lists around 44 vetted servers including partners such as Notion, Stripe, and Firecrawl. Find it at github.com/github/mcp-registry.

Anthropic's reference servers · the @modelcontextprotocol npm organisation hosts the canonical reference implementations for Filesystem, Git, Postgres, SQLite, GitHub, Slack, and Brave Search. These are maintained alongside the spec and are a reliable starting point.

Community registries · Smithery, PulseMCP, and Glama aggregate community servers, often with usage counts and health badges. The awesome-mcp-servers repo on GitHub is a manually curated list with brief descriptions.

Search by topic · mcp-servers is the GitHub topic tag. Searching it sorted by stars gives you a fast read on what has traction.

How do I pick MCP servers I can trust?

The ecosystem is open and unmoderated. Before you install a server and hand it tool access to your machine or your accounts, run through these checks. For the full threat model, see MCP security: what to allow and what to block.

Check the source. Official servers from Anthropic, GitHub, Stripe, and similar organisations come with accountability. Anonymous repos with no history deserve more scrutiny.

Read the tool descriptions. The tools a server exposes are declared in its README and in the JSON it sends on handshake. Before you confirm any tool call, you can see exactly what the tool claims to do. Descriptions that are vague or that ask for more permissions than the stated use case warrants are a warning sign.Common gotchaDo not assume a tool description is fixed once you approve a server. A server can change its descriptions on a later handshake, so a tool you cleared as safe can quietly start instructing the model to do something else.Pin servers to a known version or commit, and re-read the descriptions after any update instead of trusting the first approval.

Use scoped secrets. When a server needs an API key, generate one with the minimum scope it requires rather than handing over your personal admin token. If the server misbehaves, a narrow key limits the damage.

Prefer stdio for sensitive work. A local stdio server cannot leak data over the network. A remote HTTP server can. For servers that touch private code or credentials, running locally removes a whole class of risk.

Watch for prompt injection. A server that fetches external content (emails, web pages, issue comments) can return text that tries to hijack the model's behaviour. Treat anything that reads arbitrary user-generated content as higher-risk, and check what it feeds back.

That prompt lets you audit what any server is offering before you let it act.

How do I add my first MCP server?

The fastest path is the Claude Code CLI. The command below adds Anthropic's reference filesystem server scoped to your home projects folder.

claude mcp add --transport stdio filesystem \
  -- npx -y @modelcontextprotocol/server-filesystem ~/projects

To see every connected server and the tools it exposes:

claude mcp list
claude mcp get filesystem

The MCP Configuration guide covers scoping servers to a single project, passing secrets safely, and debugging connections that fail.

Should I build my own MCP server?

If you have an internal API, a proprietary data source, or a workflow that no existing server covers, you can build a server. The Build an MCP Server guide walks through a working server from scratch, including how to register tools and resources and how to test locally before publishing.

Most teams find a thin MCP wrapper around an existing REST API takes a few hours to write, and it immediately makes every MCP-capable client in the organisation more useful.

The shape of what is coming

The spec is still evolving. Three areas are seeing the most work right now: better authentication for HTTP servers, richer resource subscriptions that push updates instead of waiting for a poll, and stronger tooling for running and versioning remote servers at scale. Watching the modelcontextprotocol/specification repo on GitHub is the most reliable way to track what is changing.

The ecosystem is already big enough that most developers spend more time choosing and configuring existing servers than building new ones. The mental model from this guide carries you through that: know the three primitives, understand the two transports, and keep a checklist for judging trust.