Who Decides an External Tool Is Read-Only?

July 26, 2026 · InfraScout Team

Standard users in InfraScout are confined to read-only tools. So are read-only Task Agents. Both boundaries work the same way: a tool is admitted if it cannot change anything, and excluded if it can.

For InfraScout's own tools that is a settled question — we wrote them, we know which ones write. For a tool on a third-party MCP server, the classification has to come from somewhere else, and this release is about where.

First, keep the declaration at all

The protocol has an answer built in. A server can annotate each tool it exposes, including a hint that says the tool only reads. That is the natural input to a read-only gate.

InfraScout was throwing it away. Tool discovery kept each tool's name and description and dropped everything else — on both transports, and in the admin catalog too. The hint never survived the trip, so every external tool read as though it wrote, and the admin UI had nothing to badge.

That is fixed: annotations now travel intact from the server through discovery, persistence, and the catalog to the portal. Where a server has done the work of declaring its tools, that work now counts.

The hint is trusted in exactly one direction. A tool declared read-only is admitted. A tool that declares nothing is excluded. We never invert that into a permissive default, because the declaration comes from a third party — believing a claim that something is safe is a decision you can make about a server you chose to register, while assuming safety in the absence of any claim is not a decision at all.

This changes behavior for existing tenants

Read-only chat roles previously saw all remote external tools, because the classification was missing entirely and the gate had nothing to act on. They now see only the ones declaring themselves read-only. If you have a remote MCP server registered and your standard users relied on its tools, they will lose access until the tools are classified — either by the server or by you, using the overrides below.

Then face what the ecosystem actually ships

Fixing the pipeline surfaced the real problem, which is that almost nobody annotates anything.

We checked our own development tenant: ten enabled servers, 591 discovered tools, and exactly one server declaring any annotations at all. Not one of the others — a firewall vendor's servers with two hundred tools each, an analyzer with eighty-three, Atlassian with forty-five, Splunk, Microsoft Learn, Context7, a time server, Twilio — declared a single hint. A read-only role could reach about thirty of roughly 440 otherwise-allowed tools.

Some of those servers have no write operation anywhere in them. A documentation search server cannot modify anything; it looks things up. Under a strictly fail-closed rule it was nonetheless invisible to standard users, and the fix could not be "wait for the ecosystem", because the ecosystem is not moving and the tools are useful now.

So a tenant admin can decide

Each tool in the picker can now be set three ways: forced into the read-only surface, forced out of it, or left to inherit whatever the server declared. Inherit is the default, so nothing changes until you say so, and the fail-closed behavior stays intact for everything you have not touched.

A Suggest read-only action pre-ticks the tools whose names look like reads, as a starting point for review rather than an answer. It only fills in the form — nothing is applied until you save, and the gate never consults the heuristic.

Two properties keep overrides from being quietly undone. Saving them never restarts an agent-hosted server, so a policy change does not bounce a running process. And rediscovering a server's tools — which rewrites the tool list wholesale — does not clear your overrides, because they are stored separately from the discovered catalog. Refreshing a server cannot silently reopen tools you closed.

What an override is, and is not

It is a policy assertion. You are recording your judgment that a tool does not change anything.

It is not enforcement. InfraScout cannot inspect what a third-party tool does when it runs. Mark a tool read-only and a read-only caller can reach it, whether or not the tool actually behaves. The dialog says this in as many words, because it is the one thing about the feature that must not be misread.

The reason we think it is the right call anyway is that you already hold more authority over this server than its own annotations do. You decided it should exist. You chose its address, supplied its credentials, and picked which of its tools may be called. Classifying those tools is one more exercise of the same authority — a higher one, in fact, than a self-declaration from the vendor. It deserves the same care you gave the other three decisions.

The knock-on for delegated runs

The same classification feeds read-only Task Agent runs, and there it fixed an outright failure.

A delegated run defaults to read-only and takes the intersection of what it was offered with what is classified read-only. External tools were absent from that classification entirely, so a run spawned in a conversation whose tool group was an external MCP server lost every one of its tools and failed with "tool not available". We watched it happen: an orchestrator delegated a virtual-machine enumeration, named the exact tool it needed in the brief, inherited the right tool group — and got nothing, because the read-only intersection dropped all of it.

Declared and admin-classified read-only tools now reach read-only runs. The spawn tool's own guidance was also corrected: it used to steer the orchestrator into the trap by advising against turning read-only off, without mentioning that doing so was the escape hatch from this specific exclusion.

What to do now

If you have external MCP servers registered, go look at them. Open the tool picker in AI Integrations → MCP Servers and check what carries a read-only badge. Where a server declares nothing and its tools genuinely only read, classify them — starting with Suggest read-only and reviewing what it proposes.

If you are running your own MCP server, the better fix is upstream: annotate your tools. A declaration is a statement by whoever wrote the tool, which is a stronger foundation than a judgment made by whoever registered it.

Full details in MCP Servers and Security Architecture. Questions? info@infrascout.cloud.