The Model Context Protocol (MCP) is an open standard for connecting AI applications to outside tools and data. Anthropic introduced it in late 2024, and it has since been adopted across the industry. Instead of every AI app writing custom integrations for every service, a service exposes one MCP server, and any MCP-compatible client can use it.
A useful comparison is USB-C: one connector shape, many devices. MCP standardises how an AI assistant discovers what a server can do, calls it, and receives results.
The three building blocks
- Hosts and clients: the AI application (for example Claude Desktop, Claude Code, an IDE or your own agent). The client keeps a connection to each server.
- Servers: programs that expose capabilities. A GitHub server can open issues; a database server can run queries.
- Primitives: what a server offers. Tools are functions the model can call, resources are data it can read, and prompts are reusable templates.
Under the hood, messages use JSON-RPC 2.0. A client asks the server which tools it has, the model decides when to call one, the client sends the call, and the server returns structured content.
Local vs remote servers
| Local (stdio) | Remote (HTTP) | |
|---|---|---|
| Runs where | On your machine, started by the client | On the provider's servers |
| Typical setup | A command such as npx or uvx in a config file | A URL plus OAuth sign-in |
| Good for | Files, local repos, dev databases | SaaS products (issue trackers, payments, CRMs) |
| Main risk | Code runs with your user's permissions | The scope of the access you grant |
Our MCP directory labels each server as local, remote or both.
A minimal example
Many desktop clients read a JSON config that lists servers to launch. A local reference server looks like this:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/folder"]
}
}
}
The path argument limits which folder the server may touch. Always scope local servers as tightly as possible.
How to choose an MCP server safely
- Prefer official servers published by the vendor whose product you're connecting (marked Official in our directory) or the reference servers from the MCP project.
- Read what tools it exposes. A "read-only" use case shouldn't require write or delete tools; many servers have read-only modes.
- Watch for prompt injection. Content a server returns (web pages, issues, emails) can contain instructions aimed at the model. Keep a human approval step for actions with side effects.
- Use least-privilege credentials: scoped tokens, test accounts, and separate keys per server.
- Check maintenance: recent commits, a security policy, and how quickly issues are answered.
MCP vs plain APIs
MCP doesn't replace REST APIs; most servers are thin wrappers around them. The value is discovery and consistency: the model learns what's available at runtime, and you configure an integration once for every MCP-capable client. If you're building a product, offering both a documented API and an MCP server is quickly becoming the norm.