simulate_transaction_risk

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the meaningful distinction that no RPC simulation is performed, implying this inspects policy rather than chain state. The capability/tier/API-path preamble is internal metadata rather than behavioral context for the agent.

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 two substantive sentences are tight and front-loaded after the header. However, the bracketed capability/tier/API/authority preamble is internal plumbing that the agent cannot act on and crowds out parameter guidance.

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 read-only, idempotent check tool with no output schema, the description should say what the result means (pass/fail, violations) and how the three parameters interact. It delivers the safety framing but omits both the return semantics and any parameter explanation, leaving real gaps for a nested-object input.

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% with three parameters, including a nested expectedTransaction object carrying dataHash and a walletAddress with a strict pattern. The description explains none of them: what expectedTransaction is matched against, when walletAddress is required, or why value/chainId live inside transaction. Only type constraints in the schema carry any meaning.

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?

States a specific verb and resource: applying Camp Guard transaction policy checks to an unsigned transaction. The clause 'This is not an RPC simulation' usefully separates it from RPC-style simulation siblings, though it does not distinguish it from policy_check_intent or simulate_intent.

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?

No positive guidance on when to call this versus policy_check_intent, simulate_intent, or run_risk_sentinel, all of which sound adjacent. The only routing signal is a negative one ('not an RPC simulation'), which helps but leaves the sibling choice unresolved.

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