What is an MCP?
A plain-language guide to the Model Context Protocol — what it is, how it works, and why it matters.
The short answer
The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, that lets AI applications like Claude connect to external tools, data sources, and services in a consistent way. Instead of an AI model being limited to what it already knows, an MCP server gives it live, structured access to things like your filesystem, a database, a SaaS product, or a search engine — through one shared protocol instead of a custom integration for every combination of AI app and tool.
A common way to describe it: MCP is like a USB-C port for AI applications. One standard connector, many compatible devices — instead of a different cable for every combination of laptop and accessory.
The problem MCP solves
Before MCP, every AI application that wanted to talk to an external system needed its own, purpose-built integration. If you had M AI applications and N tools or data sources, you could end up needing something close to M × N separate integrations — each one built, tested, and maintained independently, often by different teams using different conventions.
MCP collapses that down to M + N: a tool or data source is wrapped once as an MCP server, and any MCP-compatible client can immediately use it. The integration work happens once, not once per client.
How MCP works
MCP defines three roles that communicate using a standard JSON-RPC 2.0 message format:
- Host — the AI application the user actually interacts with, such as Claude Desktop, Claude Code, or an IDE like Cursor.
- Client — lives inside the host and maintains a single, stateful connection to one MCP server.
- Server — a lightweight program, running locally or hosted remotely, that exposes a defined set of capabilities over MCP.
A host can run many clients at once, each connected to a different server, which is how a single AI assistant can simultaneously have access to, say, your filesystem, a GitHub account, and a database.
What can an MCP server do?
Every MCP server can expose up to three primitives to the client that connects to it:
- Tools — executable functions the model can decide to call on its own, such as “create a GitHub issue” or “run this SQL query.”
- Resources — structured or unstructured data the client can read and attach as context, such as a file’s contents or a database record.
- Prompts — reusable, parameterized prompt templates that a user can select to kick off a specific workflow.
More advanced servers can also use sampling, where the server asks the connected client’s model to generate a completion on its behalf — useful for agentic workflows that need their own reasoning step without managing their own model access.
Local vs. remote servers
MCP servers connect to clients over one of two transport styles:
- Local (stdio). The server runs as a subprocess on your machine (commonly launched via
npxoruvx) and communicates over standard input/output. This is fast and well suited to servers that need access to local resources, like your filesystem. - Remote (HTTP). The server is hosted somewhere and the client connects to it by URL. This suits SaaS integrations, servers shared across a team, or servers you don’t want to install and update locally.
Real-world examples
MCP servers exist for a wide range of categories, including:
| Category | What it enables |
|---|---|
| Developer tools | Read and manage GitHub/GitLab issues and pull requests from chat |
| Databases | Query a Postgres or SQLite database using plain language |
| File systems | Read and write local files as part of a coding or research workflow |
| Productivity | Search and update tools like Slack, Notion, or Google Drive |
| Web | Search the web or fetch and read specific pages |
| Commerce | Interact with payment and commerce platforms like Stripe |
You can browse working examples of all of these in the AllMCPs directory, organized by category.
Is MCP safe to use?
An MCP server can execute code, read local files, or access accounts on your behalf, so it deserves the same scrutiny you’d give any piece of software with real permissions. A few habits go a long way:
- Only connect to servers from sources you trust, and prefer actively maintained ones.
- Review what tools and permissions a server requests before enabling it — don’t grant broader access than a task needs.
- Be cautious with servers that pass untrusted external content (web pages, emails, third-party files) back to the model, since instructions hidden in that content could attempt to manipulate it — a risk known as prompt injection.
- Use scoped, least-privilege API keys wherever a server needs credentials, and rotate them periodically.
We track a health and verification status for servers listed on AllMCPs to help you gauge whether a listing is actively maintained before you connect to it.
Getting started in three steps
- Install or open an MCP-compatible client, such as Claude Desktop or Claude Code.
- Browse the AllMCPs directory to find a server for what you want your agent to do.
- Follow that listing’s setup instructions — usually a short configuration snippet — then restart your client.
For a hands-on walkthrough with real configuration examples, see our LLM Agents Guide. Want to build or host your own server? See How to Build an MCP Server and Deploying Remote MCP Servers.