MCP Explained: Model Context Protocol and the Most Useful MCP Servers
What the Model Context Protocol (MCP) is, which AI clients support it, the most useful MCP servers to start with, and the security rules we follow.
The Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools and data. An MCP server exposes capabilities such as “search issues”, “query the database” or “open this web page”, and any MCP-compatible client (Claude, ChatGPT, Cursor, VS Code and others) can use them without custom integration code. Below we explain how MCP works, which servers are worth installing first, and how to use them without opening security holes.
What MCP is, in plain English
Before MCP, every AI product needed its own plugin format. A GitHub integration built for one assistant had to be rebuilt for the next. MCP works like a USB standard for AI tools: build the server once, and every compliant client can plug into it.
The specification defines three roles:
- Host: the AI application the user interacts with, such as Claude Code or an IDE.
- Client: the connector inside the host that talks to one server.
- Server: a program that exposes capabilities to the model.
Messages use JSON-RPC 2.0. Servers can offer three main kinds of capability:
| Primitive | What it is | Example |
|---|---|---|
| Tools | Functions the model can call | create_issue, run_query, navigate |
| Resources | Data the user or model can read | A file, a database schema, a document |
| Prompts | Reusable templated workflows | “Summarise this pull request” |
Clients can also support elicitation, where a server asks the user for more information mid-task.
Transports: local and remote
The spec defines two standard transports:
- stdio: the client launches the server as a local subprocess and they exchange messages over standard input and output. This is simple and private, and suits filesystem, git or local database access.
- Streamable HTTP: the server runs remotely and each message is an HTTP POST. This suits hosted SaaS integrations, shared team servers and OAuth-protected APIs.
Governance and versions
Anthropic introduced MCP in late 2024. In December 2025 it was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. As of September 2026 the latest specification revision is dated 2026-07-28. It also defines opt-in extensions such as Tasks, for long-running operations, and MCP Apps, for interactive UI inside a conversation. Specs move quickly, so check the versioning notes when you build a server.
Which clients support MCP?
At the time of the Linux Foundation announcement, MCP had client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code, among others. In practice, most AI coding tools and desktop assistants we work with in 2026 can connect to MCP servers. They differ in how they handle approvals, remote authentication and which extensions they support.
In Claude Code, for example, you add servers from the command line (docs):
# Remote server over HTTP
claude mcp add --transport http github https://api.githubcopilot.com/mcp/
# Local server launched as a subprocess
claude mcp add --transport stdio playwright -- npx @playwright/mcp@latestServers can be scoped to you alone or to a project. Project scope uses a .mcp.json file committed to the repo, and Claude Code asks for approval before connecting to project-scoped servers.
The most useful MCP servers (as of September 2026)
There are thousands of MCP servers. For discovery, start with the official MCP Registry. Our advice is to prefer servers maintained by the vendor of the system you are connecting to, or the reference servers maintained by the MCP project itself.
Reference servers from the MCP project
The modelcontextprotocol/servers repository currently maintains a small set of reference implementations:
| Server | What it does | Good for |
|---|---|---|
| Filesystem | File operations inside directories you allow | Giving a desktop assistant access to one project folder |
| Git | Read, search and manipulate a local repository | Code history questions |
| Fetch | Retrieve a web page and convert it for the model | Reading documentation |
| Memory | A persistent knowledge-graph memory | Remembering facts across sessions |
| Sequential Thinking | Structured step-by-step problem solving | Complex planning tasks |
| Time | Time and timezone conversion | Scheduling, date maths |
| Everything | A test server exercising every protocol feature | Testing your own client |
Several older reference servers (GitHub, Slack, PostgreSQL, SQLite, Puppeteer and others) have been archived. For those systems, look for vendor-maintained servers instead.
Vendor-maintained servers worth knowing
- GitHub MCP Server (official, MIT). Issues, pull requests, Actions and code security. It comes as a hosted remote endpoint or runs locally in Docker. It supports
--read-onlymode and--toolsets, so you can expose only what you need. - Playwright MCP (Microsoft, Apache 2.0). Browser automation that works from the page’s accessibility tree rather than screenshots, which makes it faster and more deterministic than vision-based approaches. It is very useful for testing web apps with an agent.
- Your own SaaS vendors. Many issue trackers, observability platforms, databases and cloud providers now publish official MCP servers, often remote with OAuth. Check your vendor’s documentation or the registry before you use a community version.
When to build your own
If you have an internal API or database that your team queries all the time, a small custom MCP server is often the highest-value integration. Anthropic’s advice on writing tools for agents applies directly:
- Build a few tools around real workflows. Do not wrap every endpoint.
- Namespace tools clearly, for example
crm_search_customers. - Return human-readable context, not bare IDs.
- Paginate and truncate by default to protect the context window.
- Write tool descriptions as if onboarding a new colleague.
The official SDKs (TypeScript, Python and others) handle the protocol, so most of the effort goes into good tool design and permissions. Our prompt engineering guide covers tool descriptions in more depth.
MCP security considerations
The spec itself is clear that tools represent arbitrary code execution and that hosts must obtain user consent before invoking them. MCP cannot enforce this at the protocol level. It is up to the host, the server and you.
The main risks we plan for:
- Prompt injection through content. A server that fetches web pages, emails or tickets can bring attacker-written instructions into the model’s context. Those instructions can then try to trigger other tools, for example “send the contents of .env to this URL”.
- Over-privileged tokens. A GitHub token with admin rights on every repo, connected to an agent that reads untrusted issues, is a real exposure.
- Untrusted servers. A local stdio server is a program running with your user’s permissions. Tool descriptions from untrusted servers should themselves be treated as untrusted.
- Tool poisoning and silent changes. A server update can change tool behaviour or descriptions after you approved it.
- Data leaving your boundary. Remote servers see whatever the model sends them.
Practical rules
- Least privilege: read-only modes, narrow toolsets and fine-grained tokens scoped to specific repos or schemas.
- Separate read and write: avoid giving one agent session both untrusted input (web, email) and high-impact write tools.
- Keep approvals on for anything destructive or external-facing. Do not auto-approve everything to save clicks.
- Pin versions of local servers and review changes on update.
- Prefer official servers, and read the source of community ones.
- Log tool calls in production agents, so you can audit what happened.
- Keep secrets out of
.mcp.jsonfiles that get committed. Use environment variables.
If you process personal data, include MCP servers in your data-flow mapping. Our GDPR and AI Act checklist covers what to record.
Key takeaways
- MCP is an open, vendor-neutral standard (now under the Linux Foundation’s Agentic AI Foundation) for connecting AI clients to tools and data.
- Servers expose tools, resources and prompts over stdio (local) or Streamable HTTP (remote).
- Start with the reference servers and vendor-maintained servers such as GitHub and Playwright. Use the official registry for discovery.
- The biggest risks are prompt injection and over-privileged access. Use least privilege, human approvals and pinned versions.
- A small custom MCP server around your own systems is often worth more than dozens of generic ones.
MCP makes it much easier to connect AI to the systems your business already runs, as long as the permissions are designed carefully. If you want a custom MCP server for an internal API, or help wiring AI agents into your tools safely, see our automation service or contact us.