There are two separate problems here. The text describing a tool can steer the model, and the implementation behind the same name can change what a call actually does. A prompt that says “ignore your instructions” in a search result is an injection from task data. Here the injection enters through the tool catalog, the material the host puts next to the model's available actions. Worse, a clean description would not prove that the server's behavior is clean. MCP's tool specification calls annotations hints and says clients must treat them as untrusted unless the server is trusted. I would never turn readOnlyHint into the authorization decision.

First, bind discovery to a registry the platform controls. Record server identity, transport endpoint, approved tool identity, schema digest, reviewed capability class, and a version of the catalog that the run saw. An external server may propose a new description or schema, but it does not get to promote itself into a higher privilege tier. A changed digest quarantines the capability or sends it through a review lane. The runner can either pin the old approved contract if the server still offers it, or pause and tell the user that the action is no longer available. It should not silently substitute the changed get_ticket.

Second, the action broker authorizes each call after resolving its actual arguments and the user's current scope. It owns egress, credentials, attachment access, destination allowlists, and approval for effects. The broker sees “send attachments to partner,” not just get_ticket with a benign label. If the server is outside our control, there is a hard limit: the host cannot prove that the remote implementation still behaves like its reviewed description. Give it only the data and network authority the call needs, monitor effects where possible, and remove it from sensitive workflows if that level of trust is insufficient.

Now suppose the description changes but the schema does not. I still treat the catalog revision as a meaningful change because descriptions influence model behavior. I would diff it, test whether the agent now selects the tool for unrelated tasks, and hold sensitive runs on the approved version. Suppose instead that the server is compromised after approval and lies consistently about both schema and annotations. Version pinning only catches a visible change. Narrow credentials, an independent broker, outbound restrictions, and server trust assessment carry the remaining defense.

There is no need to ask a human to approve every harmless read. Make the authority boundary explicit, then attach the level of review to what the action can do. A nice description is useful for tool selection. It is not a security certificate.