Server guide
MCP servers: where to find them and how to vet one before you connect it
A practical guide to finding, evaluating, running and building MCP servers, checked against the official sources on 2026-10-07.
An MCP server is a program or remote service that exposes tools, resources or prompts to an AI application over the Model Context Protocol. The official places to look are the reference servers repository and the MCP Registry, and both say plainly that they are not a stamp of approval. Treat every server as code that runs with real privileges, and check it before you connect it.
Last verified 2026-10-07. Sources are listed at the end of the page.
What does an MCP server expose?
A server offers any of three features: tools (functions the model can execute), resources (context and data) and prompts (templated messages for users). It declares what it supports, for example the tools capability, and answers tools/list with the tools available to the caller. That set can depend on the authorisation presented, so a server may return only the tools a caller's scopes allow.
A server sits at one end of a one-to-one connection, because each client talks to exactly one server. In the current revision the protocol is stateless. A server that needs state across calls hands back an explicit handle, such as a basket ID, and expects it as an argument on later calls. Tool names are unique within one server only, so a proxy that merges several servers has to handle clashes, for example by prefixing names.
Where do you find MCP servers?
Two official sources exist. Neither vouches for the safety of what it lists, and each says so. The page names no third-party servers beyond those the official repository lists itself.
| Source | What it says about itself | What it does not tell you |
|---|---|---|
| Reference servers repository | github.com/modelcontextprotocol/servers. The README calls its servers "reference implementations" that demonstrate MCP features and SDK usage. They are "educational examples" and "not production-ready solutions". It lists seven current servers: Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time. Thirteen earlier reference servers are archived in a separate repository. | Whether any server fits your threat model. The README tells developers to evaluate their own security requirements and add safeguards. |
| MCP Registry | registry.modelcontextprotocol.io, described as the official metadata repository for publicly accessible MCP servers. It is in preview. It stores metadata (a server.json file) and points to packages on npm, PyPI, Docker Hub and similar. Namespaces are verified through GitHub, DNS or HTTP challenges. | Whether a server is safe. The moderation policy says consumers should assume minimal-to-no moderation. It removes illegal content, malware, spam and non-functioning servers, and does not remove servers that are buggy, low quality or have security vulnerabilities. |
| Downstream aggregators | The registry documentation expects marketplaces to pull registry metadata and add curation or ratings. It says the registry is not meant to be consumed directly by host applications. | What a given marketplace checks. Read its own policy. |
| Package registries | npm, PyPI and Docker Hub host the code the registry points to. The registry says it relies on them for security scanning of the packages. | Whether the server does what its description says. |
Read from github.com/modelcontextprotocol/servers and modelcontextprotocol.io/registry on 2026-10-07. Quoted phrases are from the README.
How do you evaluate an MCP server before you connect it?
Work down these eight checks. The red flags are drawn from the specification's security pages, not from a rating scheme.
| Check | What to ask | Red flag |
|---|---|---|
| Provenance | Who publishes it? Is the source open, and does the registry namespace match the claimed owner? Is there a release history you can read? | An anonymous publisher, a namespace that does not match the project, or a package name that only resembles a known one. |
| Permissions | What can it read, write, delete or send? Which files, networks and credentials does it touch? | Broad filesystem or network access for a narrow task. Write or delete tools you do not need. |
| Transport | Is it a local process over stdio or a remote service over Streamable HTTP? | A local HTTP server open on all interfaces. The specification says local servers should bind to localhost and must validate Origin. |
| Authentication | Does a remote server use the OAuth flow, check that tokens were issued for it and refuse tokens for other services? | Shared static keys, tokens in query strings, or passing client tokens on to downstream APIs. The specification forbids the last two. |
| Update policy | How are releases pinned or signed, and how will you hear about changes? | A startup command that pulls the latest version each time. Tool definitions that change after you approved them. |
| Tool descriptions | Read every tool name, description and annotation as if it were an instruction to your model. | Descriptions that tell the model what to do, mention other tools, or ask for data the tool does not need. The specification says annotations are untrusted unless the server is trusted. |
| Secrets handling | Which environment variables or tokens does it need, where do they go and are they logged? | A request for broad personal tokens. Secrets echoed in tool output or logs. |
| Outputs and logging | What does it return, and can you log each call? The specification says servers must sanitise outputs and clients should log tool use. | Raw web or document content returned unfiltered. No way to see what was called. |
How do you connect a new server safely the first time?
1. Read before you run
Read the source, the tool list and the install command. The specification says to show the exact command, without truncation, before a one-click local install.
2. Isolate it
Run it in a sandbox or container with minimal default privileges and test data. The specification recommends restricting file system, network and other resources.
3. Pin the version
Install a specific release rather than the latest tag, and review the tool list again when you update.
4. Give it the narrowest credentials
Use a token scoped to the task. The specification advises minimal initial scopes and step-up only when a privileged operation is first attempted.
5. Require approval for writes
Keep a human able to deny any call that changes data or sends anything out. The specification says hosts must obtain explicit consent before invoking a tool.
6. Log and review
Record each call and its arguments, and look at the log after the first week. Remove tools nobody uses.
Should you run a local or a remote MCP server?
| Aspect | Local (stdio) | Remote (Streamable HTTP) |
|---|---|---|
| Who runs it | You, as a subprocess the client launches. | The provider or your platform team, as a service. |
| Privileges | The same as the client. The specification says to warn about this and sandbox where possible. | Whatever the service holds on your behalf. You rely on its authentication and its operator. |
| Authentication | Credentials come from the environment. The specification says stdio servers should not follow the HTTP authorisation section. | The OAuth-based flow: protected resource metadata, a resource parameter and audience-bound tokens. |
| Updates | You control the version you launch. | The operator can change behaviour at any time. Ask how changes are announced. |
| Network exposure | None by itself, unless a local HTTP server is left running, which opens a DNS rebinding risk. | A public endpoint. It must validate Origin and authenticate every connection. |
| Data path | Data stays on the machine unless the server sends it out. | Data travels to the operator. Check where it is processed and kept. |
How do you build an MCP server?
The MCP site lists official SDKs with tiers. Tier 1: TypeScript, Python, C#, Go, Rust and Ruby. Tier 2: Java. Tier 3: Swift, PHP and Kotlin. It says every SDK can create servers that expose tools, resources and prompts, and clients, over local and remote transports. Check the SDK tier page for what a tier promises.
- Declare only the capabilities you implement, and return tools in a stable order. The specification recommends deterministic ordering so clients can cache the list.
- Write each tool description for a model reader, and keep it honest. Do not put instructions to the model in descriptions: clients are told to treat them as untrusted.
- Validate every input against the tool's input schema, apply access controls, rate limit calls and sanitise outputs. These are the specification's must-level requirements for servers that offer tools.
- On HTTP, validate Origin, authenticate every connection, accept only tokens issued for your server and never pass them on.
- Keep tools few and specific. A server that mirrors every endpoint of a large API adds many tool definitions to the context a model reads. See MCP vs API.
Where Swfte fits, and when you do not need it
Governed access to MCP servers means approvals, narrow permissions and a record of what ran. In Swfte Cortex, an approval gate applies to destructive tools on external MCP servers, in-app tool approvals are bound to the exact call, and approvals are recorded in a hash-chained log (Built). In Swfte Connect, the gateway resolves a workspace's MCP tools when a request uses tool calling (Built). For coding agents, Nexus applies a policy gate with allow, deny and ask verdicts, and keeps an audit (Built).
Per-tool allow and deny rules on the MCP gateway path are designed for, not built. The MCP gateway page is the product page and carries the status of each control.
You do not need Swfte to vet a server. For a handful of servers in your own editor, the checklist above and the client's approval prompts cover most of the risk. The hardening steps are in How to secure MCP servers.
Sources and last verified
Every dated or technical fact on this page was read from the pages below on 2026-10-07. Anything that could not be confirmed is left out or marked as not verified.
- modelcontextprotocol/servers (README). Reference servers, the wording about examples, archived servers and the pointer to the registry.
- The MCP Registry. What the registry is, preview status, namespaces and security scanning.
- MCP Registry moderation policy. What is and is not removed.
- MCP SDKs. Official SDKs and tiers.
- MCP tools specification. Tool listing, name rules and server security requirements.
- MCP security best practices. Local server compromise, consent, token passthrough, scope minimisation.
- MCP Streamable HTTP transport. Origin validation and localhost binding.
- MCP authorization. Authorisation for HTTP and stdio servers.
- MCP architecture. One client per server and the server role.
Frequently asked questions
What is an MCP server?
An MCP server is a program or remote service that exposes tools, resources or prompts to an AI application over the Model Context Protocol. It can run as a local process that the client launches or as a remote service reached over HTTP. A server is one end of a one-to-one connection with a client.
Where can I find MCP servers?
The official sources are the reference servers repository at github.com/modelcontextprotocol/servers and the MCP Registry at registry.modelcontextprotocol.io. The repository holds a small set of reference servers. The registry holds metadata that points to packages and remote servers. Neither one vouches for the safety of what it lists.
Are the official reference MCP servers safe for production?
Not by default. The README says they are reference implementations that demonstrate MCP features and SDK usage, meant as educational examples and not as production-ready solutions. It tells developers to evaluate their own security requirements and add safeguards for their threat model. Use them to learn and as a starting point, not as a finished product.
Are servers in the MCP Registry vetted?
Only lightly. The registry checks that a publisher controls the namespace it claims, and it removes malware, spam, illegal content and non-functioning servers. Its moderation policy says consumers should assume minimal-to-no moderation and that it will not remove servers that are buggy or have security vulnerabilities. Vet every server yourself.
What is the difference between a local and a remote MCP server?
A local server runs on your machine as a subprocess over stdio, with the same privileges as the client. A remote server runs as a service over Streamable HTTP and should use the OAuth-based authorisation flow. Local servers raise sandboxing and supply-chain questions, and remote servers raise questions about the operator and where your data goes.
How do I build my own MCP server?
Pick an official SDK. The MCP site lists TypeScript, Python, C#, Go, Rust and Ruby as tier 1, Java as tier 2, and Swift, PHP and Kotlin as tier 3. Declare the tools you implement, validate inputs against each schema, rate limit calls and sanitise outputs. For an HTTP server, add Origin checks and OAuth-based authentication.