# The MCP Ecosystem Explained

The MCP 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](/guides/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](/guides/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](/guides/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
OAuth. 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.Do 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.

| Category | What it gives the model | Examples |
|---|---|---|
| Version control | Read repos, open PRs, create issues | GitHub MCP, GitLab MCP |
| Filesystem | Read and write local files | @modelcontextprotocol/server-filesystem |
| Databases | Query rows, read schemas | Postgres MCP, SQLite MCP, MySQL MCP |
| Search | Live web results, knowledge lookups | Brave Search MCP, Exa MCP |
| Browser automation | Navigate pages, click, scrape | Playwright MCP, Puppeteer MCP |
| Docs and knowledge | Fetch docs, query knowledge bases | Context7, Mintlify MCP |
| Communication | Read and send messages | Slack MCP, Linear MCP |
| Payments and commerce | Query orders, check status | Stripe MCP |
| Observability | Read logs, traces, metrics | Datadog MCP, Sentry MCP |
| Design | Read Figma frames and components | Figma MCP |
| Productivity | Read calendars, manage tasks | Notion MCP, Todoist MCP |

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](/guides/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](/guides/mcp-security-basics).

**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.Do 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.

List all the tools exposed by my currently connected MCP servers and describe what each one does.

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.

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

To see every connected server and the tools it exposes:

```bash
claude mcp list
claude mcp get filesystem
```

The [MCP Configuration](/guides/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](/guides/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.