Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses that metadata is re-fetched but no tools/call occurs, that model-side flags and tool annotations carry no approval weight, that no arbitrary tenant/endpoint/credential override exists, and how validation differs between HTTP (imported schema) and MCP (provider-side) arguments. It also states the boundary that a model cannot create, extend or broaden standing consent, which is exactly the kind of safety context annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The action and its approval model are front-loaded in the first two sentences, and nearly every clause adds a distinct constraint rather than restating the name. The prose is dense and clause-chained, which slows scanning, but little of it is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter, nested-argument tool with no output schema, the description covers approval, consent, validation, retry idempotency and error-avoidance constraints thoroughly. The remaining gap is the return shape: only approvalUrl is mentioned, so an agent does not know what else the preparation returns (e.g., operation identifiers to pass to execution).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the load, and it does for most parameters: requestKey is a stable UUID kept unchanged on retry, standingGrantId has a precise eligibility rule, and arguments must be a bounded JSON object validated against the imported schema or by the provider. connectionId is only implied by the 'no arbitrary tenant override' note and toolName only indirectly by 'one selected remote tool', leaving those two without explicit semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: prepare one selected remote tool call with exact JSON arguments and a stable requestKey. It also carves out scope by stating 'performs no tools/call' and that preparation does not approve execution, which functionally separates it from the execute sibling. It stops short of naming execute_remote_mcp_tool directly, so the routing signal is strong but indirect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage conditions are explicit: act after a user instruction, choose exactly one selected remote tool, show approvalUrl to the owner for browser approval by default, and pass standingGrantId only when an actual current owner-approved grant was listed for these exact arguments. It also covers the retry case (keep requestKey and arguments unchanged) and the legacy OAuth path (separate integrations consents, never silently upgrade).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.