request_human_approval

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

Annotations already declare mutation, idempotency, open-world behavior, and non-destructiveness. The description adds useful context that approval is signed via EIP-712, session-bound, and preparation-only, but it does not explain the lifecycle consequences of approval/rejection or full authorization requirements.

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 description is compact and has no redundant prose, with the core action stated after bracketed metadata. The metadata front-loading is less user-friendly than a purpose-first structure, but overall it remains concise.

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?

This is a 14-parameter, 8-required mutation tool with no schema descriptions and no output schema. The description gives some high-level context about signing and compatibility, but it is far too sparse to prepare an agent for the required fields and approval flow.

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% and there are 14 parameters, including 8 required fields. The description only indirectly touches on intentId, signature, and approval status; it provides no meaning for simulationId, policyCheckId, maxUsdValue, nonce, expiresAt, approverAddress, sessionToken, or the other fields.

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 verb and resource: submit a signed EIP-712 human approval or rejection for an intent. It adds that this is a compatibility tool and signed-only for normal callers, which clarifies its role, though it does not explicitly distinguish itself from close siblings such as submit_signed_approval or request_approval_payload.

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?

The description implies usage through 'compatibility tool' and 'signed-only for normal callers' plus capability/session-bound metadata. However, it does not explicitly say when to use this tool instead of request_approval_payload or submit_signed_approval, nor does it state exclusions.

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