MCP is an open protocol letting an agent reach outside tools and data. The more you connect, the more it can do — and the more dangerous it is. Here is how to grade tools by risk, and one principle that beats everything: the minimum tool set.
In this pagewhat MCP is, risk tiers, the cost of third-party servers. Not in this pagewhich servers I run.
In one line: an open protocol for a model to talk to outside tools.
Before it, every tool needed adapting to every agent. With it, each side implements once — a server (the capability: a database, an API, a filesystem) and a client (the agent). Any combination works.
In practice, what you feel is: install an MCP server, the agent gains a set of abilities. Which is exactly where the risk comes from — it is too easy.
There are many ways to grade tools; this one is the most useful, because it maps directly onto how irreversible the damage is:
| Tier | Capability | Worst case | Default stance |
|---|---|---|---|
| 🟢 Read-only | Read files, query databases, search | It read something it should not (still on your machine) | Fine to enable |
| 🟡 Local write | Edit files, run commands, change config | Broken local state. Version control undoes it | Depends; configure permissions |
| 🔴 Outbound | Send messages, email, call external APIs, move money, publish | Irreversible, and possibly on someone else | Off by default |
Mistakes in the first two stay on your machine. You can roll back and retry. Once the third executes, the thing has left — message sent, money moved, post public.
And it is the tier most likely to get installed casually: a notification hook, an email connector, an auto-publisher. Each looks convenient on its own.
Recommended stance: keep a human confirmation on red capabilities, even at the cost of full automation. That is page 10's third test — can you absorb it being wrong — made concrete.
Read-only tools pull sensitive content into context; outbound tools send context out. Each looks acceptable alone; together they form a complete exfiltration path.
That is what makes the previous page's second threat layer genuinely dangerous: a fooled agent holding both categories can be talked into shipping your secrets in one sentence.
An MCP server is a real program, running on your machine, usually with whatever permissions you gave it. Installing one is, in trust terms, identical to installing an unfamiliar CLI tool and running it.
And it carries one extra layer: its tool descriptions enter the model's context — text written by the server's author is read by the model as instruction-shaped content.
Three defences:
① prefer ones that are open source and traceable;
② check what permissions it asks for — a weather tool wanting your home directory is wrong;
③ run anything uncertain in an isolated environment first
(Docker or a remote sandbox — page 17).
The part people miss: every enabled tool spends context on its name and description.
| Consequence | Why |
|---|---|
| More expensive | Tool definitions are fixed overhead resent every turn (page 9) |
| Less accurate | More options, more chance of the wrong pick. One-of-twenty goes wrong more often than one-of-five |
Most tools can be toggled at will (Hermes uses hermes tools).
The right posture is a small standing set, extended when needed,
not "it does not hurt to leave everything on".
Self-check: can you list, from memory, what is currently enabled? If not, you have too many.
| Yes | Not yet |
|---|---|
| Read files / search | Anything that sends messages or email |
| Run commands (with deny rules set) | Anything touching payments, transfers or orders |
| Version control operations | Anything that publishes content |
| Fetch web pages (read-only) | Anything that can change your account settings |
The right column is not "never" — it is "once you have a feel for how this behaves". Two weeks, then decide what to add.
hermes tools.
Official docs, checked 2026-08-21.