Hi, I'm Lena. I wasn't planning to write about MCP this week. I was just trying to wire up a second tool server to a Hermes Agent instance I've been running, and somewhere between editing the config and watching a tool list refresh, I stopped.
The agent now had access to four servers it hadn't had ten minutes earlier. I hadn't really thought about what each one was allowed to read. I went back to the docs. Then I went back to the config. That's where I'll leave the intro for now — because that small pause is basically what this whole post is about.
This isn't an MCP intro. If you're here, you probably already know what the protocol is. What I want to write down is what I've been learning about using MCP with Hermes Agent without quietly handing the agent more than I meant to.
What MCP actually adds to Hermes Agent
External tool access without native Hermes tools
Hermes ships with a fixed set of built-in capabilities. MCP is how you extend that set without writing a new native tool. You point Hermes at a server — local or remote — and that server's tool list shows up alongside the built-ins. From the agent's perspective, there's almost no difference.
That "almost" matters. Built-in tools live inside Hermes' own permission model. MCP tools live behind a protocol boundary, and what they actually do on your machine or your network depends entirely on the server you trusted.
Why MCP is an adapter layer, not a magic feature
I keep reminding myself of this. MCP doesn't make a tool safer or smarter. It standardizes how a tool gets described to the agent, and how calls and responses move back and forth over JSON-RPC 2.0. That's it.
So when something goes wrong with an MCP tool in Hermes, the bug is almost never in MCP. It's in the server you connected, the credentials it's using, or the assumption that "the agent will figure out the right thing to call." I had to learn that one twice.
When to use MCP, and when not to
Good fits, bad fits, and overexposed tool surfaces
Where MCP genuinely earns its place in a Hermes setup:
- Read-heavy work over external systems — pulling issues, querying logs, fetching docs, browsing files an agent can't natively reach.
- Internal APIs you already trust, wrapped in a small MCP server you control.
- One-off integrations where writing a native Hermes tool would be overkill.
Where I'd think twice:
- Anything destructive over production systems. Deletes, force-pushes, schema changes — the agent will happily call them if a tool description sounds confident enough.
- Servers exposing dozens of tools at once. Anthropic's engineering team has noted that most MCP clients load all tool definitions upfront into the model's context, which means more connected servers means more tokens, more surface area, and more places where a tool description can quietly shape behavior. Researchers separately documented that tool descriptions themselves get fed into the LLM and can carry hidden instructions — what's now widely called tool poisoning. A bigger surface is a bigger window.
- Random community servers, especially ones that ask for broad credentials. The MongoDB team puts it directly in their docs: Streamable HTTP servers should stay bound to localhost (127.0.0.1) by default, because binding to 0.0.0.0 exposes them to the entire local network. A lot of "just works" tutorials skip that part.
If a workflow is rare, sensitive, or short-lived, MCP is probably not the right shape for it. Build it as a script and call it explicitly.
Configure MCP in Hermes safely
Stdio vs remote servers
Two transports. They're not interchangeable.
Stdio runs the MCP server as a child process on your machine. Hermes talks to it over stdin/stdout. It's simple, low-latency, and good for things like local filesystems or developer tooling. The tradeoff: you're executing a binary on your own machine, and the OAuth/token machinery doesn't really apply here.
Remote (Streamable HTTP) runs the server somewhere else and talks over HTTP. This is where authorization actually has teeth. Per the official MCP specification, MCP servers in this mode are now classified as OAuth Resource Servers, which means tokens have a defined scope and audience instead of being a generic API key. I think I'm starting to understand why the November 2025 spec leans so hard on this — single static API keys were quietly creating the worst version of every problem.
A rough rule I keep coming back to: stdio for things that genuinely need to be local, remote for anything that talks to a real network service. Mixing the two in the same Hermes config is fine, but I label them clearly so I don't forget which is which.
Per-server filtering, env isolation, /reload-mcp workflow
Three habits that have saved me real time:
- Filter the tool surface per server. If a server exposes 20 tools and the agent only needs 3, don't load the other 17. Hermes lets you allowlist tool names per server. This isn't paranoia — it directly shrinks the prompt-injection surface I mentioned earlier.
- Isolate environment variables. Don't dump your full shell environment into every MCP server you spawn. Pass only the variables that specific server needs, and reference secrets through expansion (e.g.,
"GITHUB_TOKEN": "$GITHUB_TOKEN") rather than hardcoding them. Other agent runtimes automatically redact variables matching patterns like TOKEN, SECRET, PASSWORD before spawning MCP processes — Hermes won't do this for you by default, so you have to be explicit. - Use
/reload-mcp deliberately, not reflexively. When you change a server's config, reload it — but check the new tool list before you keep working. A reload is the only moment you naturally re-read what the agent now has access to. I might be overthinking this, but skipping that check is how silent privilege creep happens.
Day-to-day MCP patterns that actually work
GitHub, databases, internal APIs, browser stacks
A few patterns I've watched hold up:
GitHub-style read access. Scoped fine-grained tokens. The agent can read issues, PRs, and code, but cannot push or merge. Write actions go through a human.
Databases. Read replicas only. Even then, I keep query timeouts short and result-row caps low — agents writing accidentally heavy queries is a real failure mode, not a theoretical one.
Internal APIs. Wrap them in a small in-house MCP server. Don't reuse a master service-account token — issue a narrower one specifically for the agent. Practitioners studying MCP at scale have noted that a meaningful share of MCP servers in the wild rely on long-lived static secrets like API keys or PATs, which is exactly the pattern most likely to leak. That number stuck with me.
Browser stacks. These are the highest-blast-radius integrations. A browser MCP server can navigate, click, and submit forms. I keep them off unless I actively need them, and then turn them off again.
The thread running through all of this is least privilege per server, not per agent. Each MCP server is a separate trust decision.
Common MCP mistakes in Hermes
Unsafe defaults, giant tool surfaces, stale config assumptions
Things I've done wrong, or watched others do wrong:
- Trusting that "default config" means "safe config." It usually means "easiest to demo." Worth a config audit on anything copy-pasted from a blog post, including this one — defaults are written for the simplest path, not the safest one.
- Connecting first, scoping later. The honest version is: scoping later usually means never. Set scopes when you add the server.
- Assuming a tool description is what the tool does. Tool descriptions are prompts. They live in the agent's context and shape behavior. A poisoned or sloppily-worded description can shift outcomes in ways the user never sees.
- Forgetting that config drift exists. A server that was safe last month may have updated its tool list. Reload, re-read, re-decide.
I'm not fully sure how to automate that last one yet. Probably worth coming back to.
FAQ
Do I need MCP if Hermes already has tools that work?
No. Add MCP when there's an actual gap. New servers add surface area whether you use them or not.
Studio or remote — which is "more secure"?
Wrong question. Stdio runs a binary locally; remote crosses a network. Each has different threats. Choose based on where the data and credentials actually live.
Can I just trust an official MCP server?
"Official" means the vendor wrote it. It doesn't mean the configuration you gave it is safe. Scope and tokens are still on you.
How often should I review MCP configs?
Whenever I add, remove, or update a server — and a quick scan monthly even when I haven't.
I'll probably keep watching how this evolves. The protocol is still moving, the spec is still tightening, and the patterns that look obvious now might look naive in six months. For now, the thing that's been most useful isn't a config snippet — it's the small habit of pausing when the tool list grows. That's where I'll leave it.
