A tool can be useful and still not belong in every conversation.
TL;DR
I almost installed the Cloudflare MCP servers into my default Hermes setup. Then I stopped.
The problem was not Cloudflare. The problem was persistence. MCP servers add tools, schemas, and descriptions to the agent’s tool surface. If those tools load for every session, they consume attention and context even when I am not working on Cloudflare.
That is a tax. Sometimes it is worth paying. Usually it should be paid on purpose.
What the servers would have given me
The Cloudflare setup exposed a few different kinds of capability.
The low-risk one was docs search. That is genuinely useful. A Cloudflare-native docs tool can be better than generic web search when I am building Workers, Pages, D1, R2, KV, or related infrastructure.
The authenticated servers were different. They could inspect or change real account resources. During discovery, one server exposed tools for things like listing Workers, reading Worker code, managing KV namespaces, working with R2 buckets, and querying D1 databases.
That is powerful. It is also not something I want casually hanging off every agent session.
The hidden cost
MCP tools do not only matter when they are called.
The agent has to know they exist. Tool names, schemas, and descriptions become part of the decision space. The model has to choose among them. The session has to carry enough context for them to be available.
If I am writing a blog post, debugging a local Python test, or thinking through architecture, I do not need five Cloudflare servers sitting in the room.
Even if the cost is small per tool, it is the wrong shape of cost. It is global. It applies before I know whether the task needs the tool.
That is the part I dislike.
The account-risk part
There was also an account boundary issue.
OAuth flows use whatever browser/account is active at the moment unless I am careful. For a personal setup with multiple accounts, that is a real footgun.
A docs-only server is one thing. An authenticated server tied to the wrong Cloudflare account is another.
The right default is not “install everything and sort it out later.” The right default is to keep the default profile lean and add account-bound tools only in a scoped environment.
The profile boundary
The better pattern is simple:
default Hermes profile -> common tools only
cloudflare profile -> Cloudflare MCP, OAuth, deployment work
one-off task -> add temporarily, remove afterwardThat keeps the default agent sharp. It also makes the security boundary easier to reason about.
If I open a Cloudflare-specific profile, I know why those tools are present. I know which account should be active. I know the session is allowed to think in Cloudflare terms.
That is very different from every conversation carrying every integration forever.
Stewardship of attention
This is partly a local AI principle for me.
I care about owning my tools, running things close to the metal, and keeping workflows inspectable. But ownership does not mean hoarding every integration in the default path.
Good stewardship sometimes means adding capability. Sometimes it means refusing ambient capability because it makes the system harder to reason about.
An agent should have the tools it needs for the work in front of it. Not every tool it might ever need.
Takeaway
MCP is useful. Persistent MCP is a design decision.
For my default Hermes profile, the bar should be high: recurring value, low account risk, and a context cost that is clearly worth it.
Otherwise, use the docs, use the CLI, use direct API calls, or spin up a dedicated profile for the job.
A lean agent is easier to trust.