Decode a transaction and compare with declared intent (free)

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

Annotations only cover readOnly/idempotent/openWorld; the description adds substantial context beyond them: that it is free with no API key, what it decodes per chain, the meaning of each decision outcome, and a genuine caveat that address-lookup-table accounts yield 'unknown' rather than a safe verdict. With no output schema, this return-value disclosure is exactly what the description should carry.

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 anti-blind-signing purpose, then structured by chain with parenthetical enumerations. It is dense but nearly every clause carries information a caller needs; the decoded-operation lists are the only slightly padded part.

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?

With no output schema, the description does the heavy lifting on return semantics and unknown-handling, and it labels chain-specific parameters. It stops short of stating which parameter combinations are required (0 are marked required) or what happens on undecodable/malformed input beyond the lookup-table case.

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 83%, so the schema already documents parallel EVM-only vs Solana-only fields, the base-units convention for amount, and network semantics. The description echoes the chain split ('EVM: ...', 'Solana: ...') but adds no format or validation detail beyond what the schema provides. Baseline 3 for high coverage is appropriate.

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?

Opens with a precise framing ('Anti blind-signing') then states the exact verb and resource: decode calldata / a base64 Solana transaction and compare against declared intent. It enumerates the specific decoded operations (ERC-20 transfer/approve/permit, setApprovalForAll, SPL TransferChecked, SetAuthority, etc.), which clearly separates it from siblings like verify_payment_requirements or payment_decision.

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?

Gives a clear decision rule tied to the tool's use: match = proceed, mismatch = 'do not sign', unknown = not the same as safe. This tells an agent how to act on the result. It does not, however, explicitly contrast when to reach for this versus siblings such as verify_payment_requirements or payment_decision.

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