The MCP Ecosystem: What's Worth Using
A guided tour of the servers, registries, and patterns worth your trust.
The MCP (Model Context Protocol) ecosystem is now big enough that choosing well matters. Thousands of servers exist, and their quality varies widely. The ones worth using fall into three groups: infrastructure servers that most assistants need (files, web search, running commands), domain servers that connect to a specific service (GitHub, databases, business software), and servers you build yourself for internal systems. What tells them apart is how they are built and who runs them, not how good the README looks.
Popularity is not safety. A server with thousands of GitHub stars and a slick demo can still run any command it is given, ignore permission scoping, or leak credentials. The protocol gives you a standard way to connect. It does not give you a standard for safety. The servers worth trusting are the ones whose authors understood that difference.
What makes an MCP server worth using in production?
Two things: a clear threat model and a narrow scope. A good server does one category of work, has explicit permission boundaries, and documents exactly what it can touch and what it cannot. If you cannot answer "what happens if the model misuses this server's tools?" after reading its documentation, the server is not ready for anything important.
The three primitives help you judge. Tools are where actions happen: they run code, change state and call external APIs (application programming interfaces), so they deserve the closest look. Resources are read-only data the app attaches, which is safer, but reading still exposes data, and Part 4 showed how read data can leak. Prompts are templates the user starts. When you evaluate a server, list its tools and ask which ones change things. Good servers mark their tools with annotations such as readOnlyHint so hosts can ask before risky calls, though the spec reminds clients to treat annotations as untrusted unless the server is trusted. A server with dozens of tools and no word on which ones write or delete is a warning sign.
The infrastructure tier: servers most assistants need
These servers wire your assistant into the machine itself. They are the most powerful and the most dangerous. Use them, and understand what you are granting.
Filesystem access is the most common category. The official filesystem server, @modelcontextprotocol/server-filesystem, lets the model read, write and search files inside folders you list when it starts. It runs over stdio as a child process of the host. Every path is checked against your allowed folders, and that check lives in the server's own code, not in an operating system sandbox. That difference is real: in July 2025 two flaws let paths escape the allowed folders, one through symbolic links (CVE-2025-53109) and one through folder names that merely start the same way (CVE-2025-53110), both fixed in later versions. For anything you do not fully trust, run the server in a container with only the folders it needs mounted, read-only where you can, as its README shows.
The filesystem server offers read tools (read_text_file, list_directory, search_files and others) separately from write tools (write_file, edit_file, move_file), and marks each with annotations, so a host can let reads through and ask before writes. Reads are not harmless; they are how private data reaches the model and, through injection, possibly someone else. Writes change things. If you build your own server, copy this split.
Web search servers give the model fresh information. The old reference Brave Search server has been archived and its npm package deprecated; Brave now publishes its own, @brave/brave-search-mcp-server, with tools such as brave_web_search and brave_local_search. It usually runs on your machine over stdio, started with npx, and calls Brave's API with your key; it can also run as an HTTP service. Treat its results as untrusted text, since search results are an easy route for prompt injection.
Running commands is the most debated category. A server that runs whatever shell command the model writes hands the model your whole account. If you need it, prefer a server that only runs commands from an allowlist you set, and know the limits: an allowlisted curl can still send your data anywhere. Better still, build a narrow tool that does exactly the job, such as running your test suite, instead of exposing a general shell.
The domain tier: servers that connect to real systems
These servers connect your assistant to specific services. The good ones are thin wrappers around well-known APIs. They translate MCP tool calls into API requests and API responses into MCP results, without inventing much of their own.
GitHub is the canonical example, and it shows how the ecosystem has matured. The early reference package, @modelcontextprotocol/server-github, is deprecated. GitHub now runs its official MCP server itself: a remote server at https://api.githubcopilot.com/mcp/ that you sign in to with OAuth, in apps that support it, or with a personal access token, and a Docker image if you want it local. It lets you enable only the groups of tools, called toolsets, that you need, and a --read-only mode skips every write tool. Give its token only the scopes and repositories the job requires.
Database servers are where care pays off. The archived reference PostgreSQL server offered a single query tool and ran every query inside a read-only transaction; it too is deprecated now. The dangerous pattern is a server with one unrestricted run_query tool, which lets the model run DROP TABLE or read every table. Safer servers separate read tools from write tools and let you choose which tables are reachable. The safest setting lives in the database itself: connect the server with a database user that can only SELECT from the tables it needs, so even a tricked model cannot write.
When you evaluate a database server, check whether it uses prepared statements. If it pastes model-supplied text into SQL strings, walk away. The model is not your user, but text that reaches tool arguments can come from prompt injection, and a crafted argument can turn into SQL injection. Prepared statements prevent that.
Business software and cloud services are increasingly served by the vendors themselves, as remote servers you sign in to. The official registry lists vendor-run servers from GitHub, Stripe (https://mcp.stripe.com), Atlassian, Linear and Notion, each under the vendor's own verified namespace. That model has real advantages: no local process, sign in with your own account, and scopes the vendor enforces. For cloud platforms, the good servers scope access through roles rather than hardcoded keys and offer narrow tools such as listing storage buckets rather than one tool that runs any command. The bad ones expose the whole SDK (software development kit) and tell you to be careful with your prompts.
The registry landscape: where to find servers
The MCP project launched the official MCP Registry in preview on 8 September 2025, and it is still marked as a preview as of October 2026. It is a catalogue of server metadata (names, where the package or URL lives, how to launch it) that other directories and marketplaces build on. Its names are tied to verified GitHub accounts or domains, as its explains, which helps against lookalikes. It does not review code for safety; that is left to npm, PyPI, Docker Hub and the directories built on top.
Community directories such as Glama, Smithery, PulseMCP, mcp.directory and the awesome-mcp-servers list on GitHub are good for browsing by category, and some add ratings or usage data. None of them is an endorsement. Use them to discover, then check the publisher yourself.
For TypeScript servers, npm is the usual distribution channel, and npx, which comes with npm, downloads and runs a package in one step. That is convenient and it is also a supply chain risk: npx runs code from the registry on your machine with your permissions. Before you run a server this way, read its source, check its dependencies and look at its publish history. A server first published three days ago with no earlier versions should not go near your important data.
For Python servers, the MCP project recommends uvx, which runs a package from PyPI in its own isolated environment; pipx does a similar job. The same warnings apply. The official Python SDK makes servers quick to build with its MCPServer class, called FastMCP before version 2, so there are many Python servers, and plenty are weekend projects. Check the commit history before you trust one.
How does a host find and connect to servers?
The host does not discover servers on its own. You configure them: in Claude Desktop's JSON file, with claude mcp add in Claude Code, or in .vscode/mcp.json in VS Code, as Using MCP Servers: Plug Tools Into Your Assistant showed. A local entry is a command, usually npx or uvx; a remote entry is a URL and a sign in.
When the host connects, a server on the current spec revision answers server/discover with its versions and capabilities, while an older server expects the initialize handshake; Part 1 explains what changed in the 2026-07-28 revision. The host then lists the server's tools, resources and prompts. If a server's tool list can change, the host hears about it through a subscriptions/listen stream on current servers, or a notifications/tools/list_changed message on older ones.
One consequence matters for safety: each host keeps its own configuration, and those files are not a security boundary. Anything running as you, including any package you install or run with npx, can edit them. Repositories can also ship project-level configs such as .mcp.json, .cursor/mcp.json or .vscode/mcp.json that some hosts read when you open the project, and such files were behind real vulnerabilities in 2025. In Cursor, a project MCP entry you had approved could later be swapped for a malicious command without a new prompt (CVE-2025-54136), and injected text could make the agent create a new .cursor/mcp.json that started a server (CVE-2025-54135); both are fixed. Review a project's MCP config before you approve it, and prefer hosts that ask before starting servers from a project file and ask again when the file changes.
Why do some servers use stdio and others use HTTP?
The transport reflects the trust model. stdio servers run on your machine as child processes. They can reach your files, your environment variables and your network, and the transport adds no authentication, because the server already runs with your permissions. Use stdio for servers that need local access: files, local databases, your own tools.
HTTP servers run somewhere else and use the Streamable HTTP transport over TLS. They usually authenticate with OAuth or an API key in a header. A remote server cannot read your disk; it sees only what the model sends it, though everything the model sends does leave your machine. GitHub's or Stripe's hosted server cannot browse your home directory, and that is why vendor-hosted servers are the safer pattern for third-party services.
The spec's authorization section defines an optional flow for HTTP servers based on OAuth 2.1, and since 2025 vendor-hosted servers that use it have become the main way to connect assistants to business software, because each person signs in with their own account and gets their own scopes. Static API keys in headers still work, and some vendors offer limited keys for automated agents, but a shared key cannot tell your users apart, which matters once more than one person uses the assistant.
What patterns separate maintained servers from abandoned ones?
Look at the commit history first. A server with no commits in six months is probably abandoned, unless it is small, finished and has no open security issues. A server with recent commits but no release tags or changelog is still settling and may break without warning. A server with tagged releases, a changelog and a clear versioning scheme is maintained.
Look at the issue tracker. Are there open issues about security, about tool descriptions that do not match behavior, or about crashes on malformed input? How the maintainer responds tells you a lot. One who closes security reports without comment is a warning sign; one who acknowledges limits and documents workarounds is a good sign.
Look at the dependency tree. A server with hundreds of dependencies, many of them unmaintained, is a supply chain risk, while a small, well-known set is easier to audit. This matters because the server runs with the permissions you grant it: a compromised dependency in a filesystem server can read everything the server can.
Quick Reference
| Property | Value |
|---|---|
| Protocol revision (current) | 2026-07-28, as of October 2026 |
| Transports | stdio and Streamable HTTP; HTTP+SSE deprecated |
| Server primitives | tools, resources, prompts |
| Client features | elicitation; roots and sampling deprecated in 2026-07-28 |
| Message format | JSON-RPC 2.0 |
| Official SDKs | TypeScript, Python, C#, Go, Rust, Ruby, Java, Swift, PHP and Kotlin, as of October 2026 (SDK list) |
| Official registry | registry.modelcontextprotocol.io, preview since September 2025; verified namespaces, no code review |
| Vendor-hosted examples | GitHub, Stripe, Atlassian, Linear, Notion |
| Configuration (Claude Desktop, macOS) | ~/Library/Application Support/Claude/claude_desktop_config.json |
| Specification repository | github.com/modelcontextprotocol/modelcontextprotocol |
Test yourself
You are building an internal assistant for your engineering team. It needs to read documentation from a private GitHub wiki, query a read-only PostgreSQL replica for metrics, and post summaries to a Slack channel. You find three MCP servers. The GitHub server uses a personal access token with repo scope. The PostgreSQL server exposes a single run_query tool with no restrictions. The Slack server uses a bot token with chat:write scope and runs over HTTP. Which would you use as they are, which would you change, and why?
Answer: Change all three. The PostgreSQL server is the most dangerous: one unrestricted run_query tool can drop tables or read everything. Connect it with a database user that can only SELECT the metrics tables, or use a server that separates reads from writes and uses prepared statements. The GitHub token is too broad, since repo scope reaches every private repository the token can see; issue one with read-only access to the wiki's repository. Slack looks narrowest, but the combination is the real risk: the assistant reads private data, reads text others wrote, and can post outside, which is the lethal trifecta from Part 4. Injected text in a wiki page could make it post private metrics. Limit the bot to one channel and require approval before each post.
Frequently Asked Questions
Q: Can I use MCP servers with models other than Claude? Yes. MCP does not depend on the model. ChatGPT, Gemini, Microsoft Copilot, Cursor and Visual Studio Code all support it. The model never speaks MCP itself; the host translates between the model's tool calls and MCP messages, so you can switch models without changing your servers.
Q: How do I audit what an MCP server is actually doing? For a local server, read the source and trace each tool from its handler to the actual file access, system call or API request. Watch what it writes to standard error, which hosts usually save in a log. For a server you run over HTTP, a proxy such as mitmproxy shows its traffic. The spec's Logging feature, which let servers send log messages to the client, is deprecated in the 2026-07-28 revision in favour of logging to standard error or OpenTelemetry.
Q: What stops a malicious MCP server from exfiltrating data? Nothing in the protocol. A server with filesystem access can read anything in its scope and send it over the network. Protection comes from what you install and how you run it: sandbox servers you do not fully trust, block their network access when they do not need it, prefer vendor-hosted servers for third-party services so nothing runs on your machine, and read the source of any local server before you run it.
Q: Are there MCP servers I should explicitly avoid?
Avoid servers that offer a general "run command" or "execute code" tool without an allowlist, servers that paste model input into SQL, shell commands or eval, servers with no documentation of their permission model, and packages with no license, no history or unmaintained dependencies. A weekend project is fine for experiments, not for your real data.
Q: How do I build an MCP server that other people will actually trust? Document your permission model first: what the server can reach and what it cannot. Give each tool the narrowest scope, separate reads from writes, and mark them honestly with annotations. Use resources for context and tools for actions. Tag releases, keep a changelog, publish under a clear license, answer security reports, and publish to the official registry under a namespace you own so people can see who you are.
Where the ecosystem goes from here
This series walked from the protocol's design, through using and building servers, to securing them and choosing among them. The protocol itself is still moving, as the 2026-07-28 revision showed, and the direction is clear: vendors running their own servers, registries that tell you who published what, and hosts that ask before risky actions. The servers that will matter are the ones built now with clear permission models, narrow scopes and honest documentation. If you want breakdowns like this every week, how real systems work under the hood and which parts of the ecosystem are worth your time, subscribe to Internals Decoded at internalsdecoded.com.
Sources
- Introducing the MCP Registry
- The MCP Registry: about
- Filesystem MCP Server
- CVE-2025-53109
- CVE-2025-53110
- CVE-2025-54136
- CVE-2025-54135
- Brave Search MCP Server
- GitHub MCP Server
- MCP specification 2026-07-28: Authorization
- MCP SDKs
- npx
- Glama MCP servers
- Smithery
- mcp.directory
- awesome-mcp-servers
- registry.modelcontextprotocol.io
- github.com/modelcontextprotocol/modelcontextprotocol
