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

Goes well beyond the destructiveHint=true annotation by disclosing the payment model: PAID x402/USDC, $0.25 max tier charged upfront, x402 difference recorded as owed, Arc rail captures only the used tier, and no charge if it errors for lack of paths. That is exactly the cost/side-effect context an agent needs before invoking a billed mutation. It stops short of stating failure/retry or rate-limit behavior, so not a 5.

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-loads the identity and the paid/naming, then the mechanics, then billing and edge cases; most sentences carry distinct information. The billing sentence is dense (upfront charge, owed difference, Arc rail capture) and could be split, but nothing 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?

No output schema, yet the description names the return shape (consensus, coherence 0-1, pass/block gate), the path cap, the paid rails, and the two failure modes. For an 8-parameter billed tool this covers what an agent needs to call it confidently; missing only retry/idempotency guidance for a non-idempotent paid call.

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 100%, so baseline is 3; the description still adds meaning by stating the 32-path cap (schema caps at 31 + Leviathan) and by explaining what signal_type actually selects as a path. It says little extra about sources, payment_header, or arc_auth_id beyond what the schema already documents.

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 the specific composition: fetches the SML Leviathan signal (squeeze/momentum/all) for a ticker, appends it as one path, and runs the coherence check. Explicitly relates it to the sibling 'interfere' ("runs the same coherence check as interfere"), so an agent can tell the two apart without opening schemas.

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?

Clear that this is the Leviathan-augmented variant of interfere and that it degrades gracefully when Leviathan is unavailable (continues on other paths) and errors before charging when no paths exist. It doesn't state an explicit when-not-to-use-this-vs-interfere rule, but the implied routing is unambiguous.

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