What Is MCP ? A Beginner's Guide to the Open Standard for AI Agents
Every AI agent needs a way to reach beyond its own model — to read a file, query a database, call an API, or search the web. Before MCP, every tool integration was custom: the agent framework wrote its own connector, its own schema, its own auth flow. Switch frameworks and you rebuild everything from scratch. MCP fixes that. It's a single open protocol — think of it as USB-C for AI agents — that defines how any model talks to any tool, so one integration works everywhere.
This guide explains what MCP actually is, how it works under the hood, and how to use it with the two frameworks covered on this site: OpenClaw and Hermes.
Before diving in, two things worth having under your belt:
- New to agent architecture? Start with what an AI agent actually is — MCP is the protocol layer that connects agents to tools, and it helps to understand what tools are before learning how they're standardized.
- Already have an agent installed? This guide assumes OpenClaw or Hermes. If not, start with the OpenClaw installation guide or the Hermes setup guide.
Quick Decision Guide
| Question | Answer |
|---|---|
| What problem does MCP solve? | Tool integrations are rebuilt from scratch for every framework — MCP makes them portable |
| Do I need MCP to use an AI agent? | No — agents work fine with built-in tools. MCP adds access to a growing ecosystem of third-party connectors |
| Is MCP a replacement for APIs? | No — it's a protocol for using APIs. The underlying service still needs an API |
| Which frameworks support MCP? | OpenClaw, Hermes, Claude Desktop, Cursor, and most major agent frameworks as of 2026 |
| Do I need to run my own MCP server? | Only if you're connecting to a private data source. Public MCP servers (filesystem, web search, GitHub) are available as installable packages |
1. The Problem MCP Solves
Before MCP, connecting an AI agent to an external tool looked like this:
- Framework A writes a custom "GitHub tool" — its own function signature, its own auth handling, its own error format.
- Framework B writes a completely different "GitHub tool" — different signature, different auth, different errors.
- Framework C does the same thing again.
- A developer who switches from Framework A to Framework B loses their GitHub integration entirely and starts over.
This is the same problem USB solved for peripherals. Before USB, every printer had its own connector type, every mouse had its own cable standard. USB didn't change what printers or mice do — it standardized how they connect.
MCP does the same thing for AI agents and external tools. It defines:
- How the agent (the "client") discovers what tools are available — a capability handshake, not a hardcoded list.
- How the agent calls a tool — a consistent JSON-RPC 2.0 message format.
- How the tool responds — a structured result or error, the same shape regardless of which tool or which framework called it.
- How auth and permissions are handled — the tool owner controls access, not the agent framework.
The result: write one MCP server for GitHub, and it works with OpenClaw, Hermes, Claude Desktop, Cursor, and any other MCP-compatible client. No rewrites.
2. How MCP Actually Works
MCP uses a client-server architecture with two roles:
| Role | What it does | Example |
|---|---|---|
| MCP Client | The AI agent or app that needs external tools | OpenClaw, Hermes, Claude Desktop |
| MCP Server | A small program that exposes a specific tool or data source | A filesystem server, a GitHub server, a Postgres server |
The communication flow:
Agent (MCP Client) ←→ MCP Protocol (JSON-RPC 2.0) ←→ MCP Server ←→ External Service
The handshake happens first. When the client connects to a server, they exchange capabilities: the server says "I can do X, Y, Z" and the client says "I need A, B, C." This is dynamic — add a new MCP server and the agent automatically discovers new tools without a code change.
The transport is how the messages actually move. MCP supports two:
- stdio — the server runs as a local subprocess, communicating over standard input/output. Fast, simple, no network. This is the default for local tools like filesystem access.
- Streamable HTTP — the server runs as an independent remote service, communicating over HTTP. The client and server exchange messages through a single HTTP endpoint, which can optionally upgrade to a stream for longer-running responses. This is the current standard transport for hosted tools or when the server runs on a different machine. (An older two-endpoint HTTP+SSE transport served this role before 2025; it's deprecated, and most clients are dropping support for it through 2026, so new setups should use Streamable HTTP.)
For most setups, stdio is what you'll use. It's the simplest option and covers local tools — file access, local databases, command-line utilities — without any network configuration.
3. What an MCP Server Actually Looks Like
An MCP server is a small program that exposes one or more "tools" — typed functions the agent can call. Here's what a minimal filesystem MCP server exposes:
| Tool Name | What it does | Input |
|---|---|---|
read_file |
Read the contents of a file | path (string) |
write_file |
Write content to a file | path (string), content (string) |
list_directory |
List files in a directory | path (string) |
The agent doesn't need to know how the server implements these — it just sees the tool names, descriptions, and input schemas. The server handles the actual file operations, including any permission checks or sandboxing.
This is the key insight: MCP separates the interface from the implementation. The agent knows what tools are available and how to call them. The server knows how to actually do the work. Neither side needs to know the other's internals.
4. Using MCP with OpenClaw
OpenClaw has native MCP client support built in. To add an MCP server, edit ~/.openclaw/openclaw.json:
{
mcp: {
servers: {
filesystem: {
command: "npx",
args: ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"],
},
github: {
command: "npx",
args: ["-y", "@modelcontextprotocol/server-github"],
env: {
GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_your_token_here",
},
},
},
},
}
Each server entry specifies:
command— what to run (usuallynpxfor Node.js-based servers).args— the arguments passed to the command.env(optional) — environment variables the server needs, like API keys.
(Field names above match OpenClaw's MCP config at the time of writing — double-check against your installed version if something doesn't load.)
After editing, validate and restart:
openclaw config validate
openclaw restart
The agent now has access to every tool those servers expose — no code changes, no custom integration. Add a Postgres server entry and the agent can query your database. Add a Slack server and it can send messages. The protocol handles the rest.
For more on how OpenClaw handles file access natively (without MCP), see how to connect AI agents to local files.
5. Using MCP with Hermes
Hermes also supports MCP natively. The configuration lives in ~/.hermes/config.yaml:
mcp:
servers:
filesystem:
command: npx
args:
- "-y"
- "@modelcontextprotocol/server-filesystem"
- "/path/to/allowed/dir"
github:
command: npx
args:
- "-y"
- "@modelcontextprotocol/server-github"
env:
GITHUB_PERSONAL_ACCESS_TOKEN: ghp_your_token_here
The structure is the same as OpenClaw — each server gets a name, a command, arguments, and optional environment variables. Hermes discovers the tools automatically on next session start.
To verify what MCP tools are available in a session:
hermes tools
This shows all enabled toolsets, including any MCP servers that connected successfully. If a server fails to start (missing dependency, bad API key), the error surfaces here rather than silently failing.
6. Where to Find MCP Servers
The MCP ecosystem is growing fast. The main hub is the official MCP servers repository on GitHub, which includes reference implementations for:
- Filesystem — read/write/list local files
- GitHub — repos, issues, pull requests, search
- Postgres — query a PostgreSQL database
- SQLite — query a local SQLite database
- Web Search — Brave Search integration
- Puppeteer — browser automation
- Memory — a simple key-value memory store
Community-maintained servers cover hundreds of additional services — Slack, Notion, Google Drive, Jira, and more. Search the repository or check mcpservers.org for a curated list.
When evaluating an MCP server, check three things before adding it:
- Does it run locally or require a hosted service? Local is simpler; hosted may need an API key or account.
- What permissions does it need? A filesystem server needs a directory path — make sure it's scoped to what you actually want the agent to access, not your entire drive.
- Is it actively maintained? The ecosystem is young. Check the last commit date and open issues before relying on it for production workflows.
7. MCP vs. Built-In Tools: When to Use Each
MCP works as an extension mechanism on top of an agent's built-in tools, not a replacement for them. Here's how to think about the boundary:
| Scenario | Use |
|---|---|
| The agent already has a built-in tool for the job | Built-in tool — less setup, tighter integration |
| You need to connect to a service the agent doesn't natively support | MCP server |
| You want the same integration to work across multiple agent frameworks | MCP server — write once, use everywhere |
| You need to connect to a private or internal API | MCP server — wrap your API in a custom server |
| The task is simple and one-off | Built-in tool or a quick script — MCP is overkill |
For example: OpenClaw and Hermes both ship with built-in web search and file access tools. If those cover your needs, there's no reason to add an MCP server for the same thing. But if you need the agent to query a specific database, interact with a niche API, or use a tool that needs to work identically across both frameworks — that's where MCP earns its place.
For a deeper look at how the built-in web tools work, see how to give AI agents web access.
8. Common MCP Issues and How to Fix Them
| Problem | Likely Cause | Fix |
|---|---|---|
| Server doesn't appear in tool list | Server failed to start | Check the command and args — run the command manually in a terminal to see the error |
| "Connection refused" or timeout | Wrong transport or port | For stdio servers, no port is needed. For remote servers using Streamable HTTP, verify the endpoint URL and that the server process is running |
| Tool call returns auth error | Missing or invalid API key in env |
Double-check the environment variable name and value — some servers expect API_KEY, others expect TOKEN |
| Tool works in one framework but not another | Different MCP client implementations | Verify both frameworks are using the same MCP protocol version; check for framework-specific config quirks |
| Server is slow to respond | Heavy operation or network latency | For local stdio servers, check disk I/O. For remote servers, check network connectivity and server logs |
The most common mistake: adding an MCP server to the config but forgetting to install the dependency it needs (usually Node.js for npx-based servers). If the server command fails silently, run it manually first:
npx -y @modelcontextprotocol/server-filesystem /tmp
If that errors, the config will error too. Fix the underlying issue, then restart the agent.
Bottom Line
MCP's whole value is portability: build or install a server once, and it works with any MCP-compatible client instead of being rebuilt per framework. Start with whatever tools OpenClaw or Hermes already ship with, and reach for an MCP server only when you need a connector they don't have built in, or one that has to behave identically across multiple frameworks.
Further reading:
- What Is an AI Agent? A Beginner-Friendly Guide — the full architecture, including how tools fit into the agent's reasoning loop.
- OpenClaw Installation Guide / Hermes Setup Guide — get an agent running, then add MCP servers on top.
- How to Give AI Agents Web Access — the built-in web tools that complement MCP-based connectors.