Search for MCP server examples and you land in a wall of roundups that stack forty logos in a grid without telling you which ones anyone still maintains. Before you wire a server into an AI assistant that can read your files and write to your APIs, the useful questions are who publishes it, what it is allowed to touch, and when it was last committed to.
The short answer: MCP servers come from three sources. Official reference servers maintained by the MCP steering group, vendor servers published by the company whose API they wrap, and community projects. The three differ sharply in maintenance, security posture, and whether they belong anywhere near production.
This guide groups real, verified servers by category, states who publishes each one, and gives you a way to judge the ones that are not on this list.
Where do MCP servers actually come from?
The Model Context Protocol is a JSON-RPC 2.0 based standard for connecting AI applications to tools and data. Anyone can write a server for it, which is exactly why provenance matters.
Official reference servers. The modelcontextprotocol/servers repository holds a deliberately small set maintained by the steering group: Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, and Time. That is the complete list. The repository is blunt about their purpose, warning that they "are meant to serve as educational examples for developers building their own MCP servers, not as production-ready solutions."
Vendor servers. GitHub, Grafana, Stripe, Linear, Atlassian, Notion, MongoDB, Redis, and others now publish and operate servers for their own products. These are the strongest category. The publisher owns the API, controls the auth model, and has a support obligation to the customers using it.
Community servers. Everything else. Some are excellent and better maintained than vendor code. Some were a weekend project in 2025 and have not been touched since. The variance is enormous, and the name in the npm package tells you nothing about which kind you have.
The archived reference servers that lists still recommend
This is the single most important thing to know before copying a config from a listicle. In late May 2025 the steering group moved fourteen reference servers into a separate servers-archived repository: AWS KB Retrieval, Brave Search, EverArt, Git, GitHub, GitLab, Google Drive, Google Maps, PostgreSQL, Puppeteer, Redis, Sentry, Slack, and SQLite. Git is the one that also survived: a rewritten implementation of it is still in the active repository, so both an archived and a maintained version exist under that name.
That archive carries an explicit warning in capital letters: "NO SECURITY GUARANTEES ARE PROVIDED FOR THESE ARCHIVED SERVERS." No security updates. No bug fixes.
Those names are precisely the ones that dominate older MCP roundups. If a guide tells you to run @modelcontextprotocol/server-postgres or @modelcontextprotocol/server-slack, it is quoting a 2025 snapshot and pointing you at unmaintained code that you are about to hand a database password to. Several of them have proper successors. Brave Search moved to an official Brave-maintained server, GitHub is now covered by GitHub's own server, and Slack now operates a hosted one of its own. Others, such as Google Drive and EverArt, simply have no direct replacement.
MCP server examples by category
Every server below was checked against its own repository or vendor documentation in August 2026. Transport values reflect what the project actually ships, not what a directory site claims.
| Server | Published by | What it does | Transport | Watch out for |
|---|---|---|---|---|
| GitHub MCP Server | Vendor (GitHub) | Repos, issues, pull requests, Actions, code security | Streamable HTTP at api.githubcopilot.com/mcp/, or local stdio binary | Default toolsets are broad. Use --read-only, GITHUB_READ_ONLY, or the /readonly endpoint |
| Playwright MCP | Vendor (Microsoft) | Drives a real browser via accessibility snapshots rather than screenshots | stdio by default, HTTP with --port | Runs an actual browser with a persistent profile. --isolated keeps state in memory |
| Git | Official reference | Read, search, and manipulate local Git repositories | stdio | A teaching example, not a production tool |
| Filesystem | Official reference | Read, write, move, and search files | stdio | Access is exactly as wide as the directories you grant via arguments or MCP Roots |
| Postgres MCP Pro | Community | Postgres access plus index and query performance analysis | stdio and SSE | Ships --access-mode=unrestricted in most examples. Use restricted outside development |
| MongoDB MCP Server | Vendor (MongoDB) | Query and manage MongoDB and Atlas clusters | stdio | Pass --readOnly unless the agent genuinely needs to write |
| Redis MCP Server | Vendor (Redis) | Manage and search data in Redis | stdio | Replaces the archived reference Redis server |
| Snowflake MCP | Vendor (Snowflake Labs) | Cortex AI, object management, SQL orchestration, semantic views | stdio and SSE | Labs project rather than a core supported product |
| Linear | Vendor (Linear) | Discover, create, and modify issues, projects, comments | Streamable HTTP at mcp.linear.app/mcp | A read-only endpoint exists at /mcp/readonly. Prefer it for research agents |
| Notion | Vendor (Notion) | Read and write Notion pages and databases | stdio and HTTP | Page access follows the integration's share scope, which is easy to set too wide |
| Atlassian | Vendor (Atlassian) | Jira, Confluence, Jira Service Management, Bitbucket, Compass | Remote, OAuth 2.1 or API tokens | One server spans five products. Scope the token, not just the connection |
| Slack | Vendor (Slack) | Search, read and send messages, manage canvases and users | Remote at mcp.slack.com/mcp, OAuth | Tools inherit the authenticating user's permissions, and a workspace admin has to approve the connection |
| AWS MCP Servers | Vendor (AWS) | A suite covering documentation, IaC, Cloud Control API, EKS, ECS, Lambda, Serverless, Support | Varies per server | It is many servers, not one. Install only the ones you need |
| Microsoft MCP catalog | Vendor (Microsoft) | Catalog of official Microsoft and Azure server implementations | Varies per server | The standalone Azure/azure-mcp repository is archived. Start from the catalog |
| Cloudflare | Vendor (Cloudflare) | Workers, DNS, analytics, and other Cloudflare surfaces | Streamable HTTP | Several distinct servers live in one repository |
| n8n | Vendor (n8n) | Build and run n8n workflows from an MCP client | Remote, OAuth or API key | Self-hosted instances can disable it with N8N_DISABLED_MODULES=mcp |
| Grafana | Vendor (Grafana) | Dashboards, datasource queries, incidents, OnCall | stdio, SSE, streamable HTTP | Supports --disable-write. Many tool categories are off by default on purpose |
| Sentry | Vendor (Sentry) | Retrieve and analyze issues and errors | Remote at mcp.sentry.dev/mcp, plus stdio | The stdio path is aimed at self-hosted Sentry and is less mature |
| Stripe | Vendor (Stripe) | Read and write across the Stripe API, search docs, run reports | Streamable HTTP at mcp.stripe.com, OAuth | stripe_api_write covers POST, PATCH, PUT, and DELETE across much of the API |
| Brave Search | Vendor (Brave) | Web and local search | stdio and HTTP | The official replacement for the archived reference server |
A few patterns fall out of that table. Vendors have largely taken over the categories that matter most, the strongest servers ship an explicit read-only mode, and the newest arrivals are hosted endpoints with OAuth rather than local processes holding a long-lived token.
How can you tell a good MCP server from a risky one?
Most MCP lists stop at "here are the tools." That skips the part that actually matters, because an MCP server is not a library you import. It is a process that runs with your privileges and holds your credentials, and the model deciding when to call it is reading untrusted text.
Five checks, in the order I would apply them.
1. Is anyone maintaining it? Open the repository and look at the last commit date, not the star count. Stars are cumulative and never go down; a server with 8,000 stars and no commits since early 2025 is more dangerous than an obscure one updated last week, because the stars are what got it into the listicle you are reading. Check whether the repository is archived. Archived is a hard stop for anything holding a credential.
2. Who publishes it? A server maintained by the company whose API it calls has an incentive structure a hobby fork does not. The vendor gets the support ticket when its own server leaks a token. Prefer the vendor server when one exists, even if a community alternative has more features.
3. How wide is the permission scope? This is the question people skip. A server that can read your issues is very different from one that can close them, and different again from one that can force-push. Look for an explicit read-only mode. GitHub has --read-only and a /readonly remote endpoint, Grafana has --disable-write, MongoDB has --readOnly, Linear publishes a separate read-only URL, and Postgres MCP Pro has --access-mode=restricted. If a server that mutates real state offers no such switch, that absence is itself a signal.
4. What is the auth model? Remote servers using OAuth 2.1 are the better shape, because you grant access without handing a long-lived API key to a client process, and you can revoke a session later from the vendor's dashboard. Servers that want a raw personal access token in a config file mean that token now lives in plaintext on every machine running the server. If you must use one, scope it down first.
5. Does it run locally or remotely, and does that match the risk? The MCP specification defines two standard transports: stdio, where the client launches the server as a subprocess, and Streamable HTTP, where each message is an HTTP POST to a single endpoint. A stdio server is a program you downloaded, executing on your machine with your permissions.
The specification's security best practices document is worth reading in full before you install anything from a directory. It names the real attack classes: confused deputy attacks against OAuth proxy servers, token passthrough, SSRF during metadata discovery, and local server compromise, where a malicious startup command in a shared config exfiltrates SSH keys. Its rule on tokens is unambiguous: MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server."
Vendors are saying the same thing in their own documentation. Stripe's MCP page tells you to enable human confirmation of tools and to be careful combining its server with others, specifically to avoid prompt injection. That warning generalizes. Once several servers are connected at once, content one server returns becomes input the model acts on when calling another.
Official, vendor, or community: what actually differs
| Official reference | Vendor server | Community server | |
|---|---|---|---|
| Maintained by | MCP steering group | The company that owns the API | An individual or small group |
| Intended purpose | Teaching SDK usage | Production access to that vendor's product | Varies, often filling a genuine gap |
| Security response | Reference quality, no SLA | Vendor security process and disclosure path | Usually none, and no disclosure path |
| Breakage risk when the upstream API changes | Low, the surface is small | Low, the publisher ships both sides | High, it is a third party tracking someone else's API |
| Auth model | Usually local, usually none | Increasingly OAuth 2.1 with revocable sessions | Frequently a raw API key in a config file |
| Read-only mode | Filesystem restricts by directory | Common and documented | Sometimes |
| Safe for production | No, per the repository's own warning | Yes, with scoped credentials | Case by case, only after you read the source |
The honest summary is that "official" is the weakest signal of the three, because in MCP terms it means "reference implementation," not "supported product." A vendor server is the one you want. A community server can be excellent, but it earns that trust by being read, not by ranking well.
Where should you look instead of a listicle?
The steering group now points at the MCP Registry as the canonical place to browse published servers, and the servers repository says so directly. It exposes a plain JSON API, so you can query it rather than trusting a curated grid:
# List published servers from the official registry
curl -s "https://registry.modelcontextprotocol.io/v0/servers?limit=20" | jq '.servers[].server | {name, description}'A registry entry is a publication record, not a safety certification. It tells you a server exists and who published it under which namespace. The five checks above still apply.
Do MCP servers have to run on your laptop?
No, and for team use they should not. A stdio server exists only while your client is running it, which means the tool works for you and nobody else, and stops existing when you close your laptop.
Remote servers solve that, which is why the vendor list above is full of hosted endpoints like mcp.linear.app/mcp, mcp.stripe.com, and api.githubcopilot.com/mcp/. You connect over Streamable HTTP, authenticate with OAuth, and the vendor operates the thing.
The gap is community servers. When a useful one exists for an internal system, or you want the community Postgres server reachable by a team rather than by one workstation, you host it yourself. That is a normal HTTP service: a container, an endpoint, credentials in environment variables rather than in a config file on each machine, and network rules deciding who can reach it. Our guide on how to deploy an MCP server walks through that end to end.
Hosting it yourself also fixes the trust problem. You pin the version, supply the credentials, and decide the blast radius, instead of every developer running an unpinned npx command that fetches whatever tag was published that morning. The same reasoning applies to any container you run for a team, and our guide to self-hosted apps with Docker covers the general shape of it.
What if no server exists for your tool?
Then you write one, and it is a smaller job than it looks. The protocol is JSON-RPC 2.0 over one of two transports, official SDKs exist for TypeScript, Python, Go, Rust, Java, Kotlin, C#, PHP, Ruby, and Swift, and a minimal server that exposes a single tool is a few dozen lines.
# A minimal MCP server exposing one tool, using the official Python SDK (2.x)
from mcp.server import MCPServer
mcp = MCPServer("inventory")
STOCK = {"SKU-1001": 42, "SKU-1002": 0}
@mcp.tool()
def get_stock(sku: str) -> int:
"""Return the current stock count for a SKU."""
return STOCK.get(sku, 0)
if __name__ == "__main__":
mcp.run(transport="stdio")Writing your own is often right for internal systems, because you control the tool surface exactly. You expose the three operations an agent should have, rather than importing a general purpose server that exposes ninety and hoping the model chooses well. A narrower server is easier to review and easier to keep read-only. See how to build an MCP server, or what an MCP server is for the protocol fundamentals first.
Frequently Asked Questions
Are MCP servers safe to install?
Not by default. An MCP server runs with your privileges and holds your credentials, and a stdio server is arbitrary code executing on your machine. The MCP specification's security best practices document names confused deputy attacks, token passthrough, SSRF, and malicious startup commands as real risks. Check the publisher, the last commit date, and whether a read-only mode exists before connecting one.
Which MCP servers are official?
Only seven: Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, and Time. Those are the reference implementations in the modelcontextprotocol/servers repository, and the repository states they are educational examples rather than production-ready solutions. Servers from GitHub, Stripe, Linear, Grafana, and similar vendors are official for their own products, which is a stronger guarantee than the reference label.
What happened to the GitHub, Slack, and PostgreSQL reference servers?
They were archived in late May 2025 along with eleven others, and moved to the servers-archived repository with an explicit notice that no security guarantees are provided and no fixes will be issued. GitHub, Brave Search, Slack, and Redis now have vendor-maintained replacements. PostgreSQL does not, so a Postgres server is a community project you should read before trusting. Older MCP roundups still recommend the archived versions of all of them.
Do I have to run MCP servers locally?
No. The specification defines stdio for locally launched subprocesses and Streamable HTTP for remote servers reached over a URL. Most major vendors now operate hosted endpoints you connect to with OAuth, so nothing runs on your machine. Community servers usually ship stdio only, so you host them yourself if you want a team to share one instance.
Can I use MCP servers with tools other than Claude?
Yes. MCP is an open standard, not an Anthropic-only feature. Vendor documentation routinely covers VS Code, Cursor, Windsurf, Zed, Codex, Gemini CLI, and other clients alongside Claude. A server that speaks the protocol correctly works with any compliant client, which is the point of standardizing on JSON-RPC and two defined transports.
Where can I find a complete list of MCP servers?
The MCP Registry at registry.modelcontextprotocol.io is the canonical index, and the official servers repository now points there rather than maintaining its own directory. It has a public JSON API you can query directly. Treat a registry entry as a publication record showing who published under which namespace, not as a safety review.
Picking servers you will not regret connecting
The useful mental model is not a ranked list. It is a short set of questions you ask about any server before it touches your credentials: who publishes it, when it was last updated, how much it is allowed to change, how it authenticates, and where it runs.
Applied to the current landscape, that means vendor servers for anything with a real API behind it, the official reference servers only for local file and Git work, and reading the source before trusting a community server with write access.
At the hosting step, an MCP server is an ordinary long-running HTTP service with unusual security requirements. Out Plane runs it as a normal app: deploy from GitHub or a container registry, get a stable HTTPS URL with automatic SSL, keep credentials in environment variable groups instead of committed config, which our environment variables and secrets guide goes into properly, restrict who reaches the endpoint with IP access profiles, and read live logs and traces when a tool call misbehaves. At least one instance always stays up, so a call never waits on a cold start, and everything runs in Nuremberg, Germany, which matters if the server touches EU personal data.
Starter and Pro both open with a 14 day free trial. Deploy from the console, or start with how to deploy an MCP server for the full walkthrough.