The most useful MCP servers we review are also the ones that can do the most damage. Observability, cloud, and warehouse servers replace a console visit with a question — and the same token that answers questions can also change things.
This page looks at three: Cloudflare MCP, AWS MCP Servers, and Snowflake MCP. The pattern that follows applies to any server whose API can mutate infrastructure.
The rule we start from
Reading is a feature. Writing is a decision. Almost every infrastructure question an agent can help with is read-shaped — what is deployed, what fired, what changed — and almost every write is something a human should sign off on. If you separate those two capabilities, most of the risk disappears.
Cloudflare: DNS and logs, not account settings
Cloudflare ships product-specific servers, hosted rather than local, covering observability, DNS, Workers, and account configuration. The hosted shape is convenient: no process to keep alive, just a scoped API token.
The two worth installing are observability and DNS. Observability answers "why did this Worker start failing" with real request data. DNS answers "what does this record point at" without a console tab. Both are read queries.
Account configuration is the part to skip. An account-scoped token is a large blast radius for a small convenience, and the questions it answers are rare.
AWS: adopt the documentation servers first
AWS Labs publishes a monorepo of servers split by service, including documentation lookup, cost analysis, and service operations. The split is the design feature: you install what you need instead of one broad server.
Start with documentation. A model that can query the official AWS docs writes better HCL and better CLI commands than one recalling blog posts. That is a meaningful accuracy gain with no write access at all.
Cost analysis is the second step: it reads billing data and answers questions that normally require a spreadsheet. Service-operation servers are the ones that need IAM decisions, and each one is a separate decision — which is exactly why we would not install them in bulk.
Snowflake: a warehouse role is the right unit of access
The Snowflake server exposes schema metadata, object descriptions, and SQL execution, and it indexes Snowflake's own documentation. That last part matters: warehouse SQL differs from standard SQL in ways models routinely get wrong.
A role limited to the databases you intend to query is the correct access model — not a user with broad grants. The distinction is not cosmetic: a role is what makes the blast radius predictable when the agent writes a query you did not expect.
A decision table
| Capability | Agent may | Human only |
|---|---|---|
| Read logs, metrics, DNS records | Yes | — |
| Read schemas, billing, documentation | Yes | — |
| Run read-only SQL | Yes, with a scoped role | — |
| Apply infrastructure changes | — | Yes |
| Change DNS records | — | Yes |
| Delete or resize resources | — | Yes |
The table is short on purpose. Every row where an agent writes to infrastructure needs a justification beyond convenience.
What makes these servers reliable
The thing that surprises people is not capability but observability of failure. A misconfigured infrastructure server does not usually error; it returns empty results. An agent asking about the wrong account will report that nothing exists, confidently.
Two habits fix this: verify the account or project ID explicitly in the first call of a session, and require the agent to quote the identifier it used. If the answer does not include an account, treat it as unverified.
The token shape that makes this safe
The difference between a safe infrastructure server and a dangerous one is usually the shape of the credential, not the capabilities of the server.
A scoped token names one account, one project, and one permission set. It is boring to create because it requires deciding exactly what the agent should see. A broad token is easy: one click, and the agent inherits everything the account can do.
The safe shape has three properties. It is read-only for anything that has a write equivalent. It is scoped to a single zone, project, or warehouse role. And it is labelled so that when you see it in the vendor console in six months, you know what it belongs to.
That last property is the one people forget. An unlabelled token from an experiment becomes permanent infrastructure, because nobody can tell whether it is safe to revoke.
Frequently asked questions
Is a hosted MCP server safer than a local one? Not inherently. Hosting changes where the process runs, not what the token can do. The token scope and the account it belongs to determine the blast radius.
Which one should a small team start with? Cloudflare observability, if they use Cloudflare. It answers real questions, reads only, and the token is easy to scope to one zone.
Can an agent safely manage infrastructure? For reads and drafts, yes. For changes, the human approval is not a formality — it is the control that makes the rest of the workflow acceptable.
Last checked: 9 November 2026.
Related: MCP servers, the MCP install checklist, and how tool definitions cost money.