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

With no annotations, the description carries the full burden and mostly succeeds: it discloses per-op return payloads, the PASS/CAUTION/DANGER/BLOCK verdict shape, the fact that prepare_* returns an unsigned transaction/message/order rather than executing, and per-op credit costs. It does not cover auth requirements, failure behavior of the safety gate, or caching semantics beyond the existence of force_refresh.

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?

Front-loaded with the use case, then exclusions, then returns, then deprecation, then metering — a sensible order with no filler. The opening sentence is dense and the metering sentence is long, but each sentence carries information an agent needs.

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 tool with 8 branches and 73 parameters, no annotations, and no output schema, the description is unusually rich on returns, cost, and aliases. The residual gap is the combinatorial parameter space: nothing tells an agent which subset of fields belongs to which op, which is the main way this definition could be misused.

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 coverage is only 53% across 73 parameters, so the description must compensate, and it does so only partially: it explains op semantics, the return per op, and per-op pricing, but never maps parameters to branches (e.g. which fields apply to prepare_perp_order vs check_safety). An agent must infer applicability from parameter names and enum values alone.

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 states a specific role — pre-execution trust decisions — and enumerates every branch it covers (oracle price, analytics, health, registry search, venue quote, safety gate, prepare_swap/prepare_perp_order). It also names the sibling tools it is not (trade_proof, oracle_watch_window, position_lifecycle), so an agent can route without opening any schema.

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?

Explicit when-to-use ("every pre-execution trust decision") paired with three explicit when-not-to-use clauses, each naming the alternative and the condition that selects it. The dispatch rule ("Each call selects the branch with 'op'") closes the remaining loop on invocation.

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