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

With no annotations, the description carries the full transparency burden. It discloses important behavioral and risk context: payments on Base are irreversible, the board verifies against its issued instruction, and the tool returns precise settlement details. It could go further by explicitly stating read-only behavior or error conditions, but 'get' and the workflow make this reasonably clear.

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 three sentences, front-loaded with the core purpose, and every sentence earns its place: what the tool returns, a critical safety warning, and the required follow-up action. There is no fluff or redundancy.

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 no output schema, the description provides a solid picture of what the caller receives and how to proceed. It names the required return fields and the irreversible risk. It is slightly incomplete on output structure and failure modes, but sufficient for selecting and invoking the tool correctly.

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?

Only 33% of the schema parameters have descriptions, and none of the missing parameter semantics are compensated in the tool description. api_key is documented, but bounty_id and submission_id receive no explanation beyond the vague notion of 'a submission'. The description does not clarify what values these IDs should take or how they relate to the settlement instruction.

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 names a specific action ('get the exact payment that settles a submission'), the resource it operates on, and the key output contents: recipient addresses, integer USDC amounts, token contract, and confirmations needed. It also differentiates itself from settle_bounty by explicitly instructing 'Pay these, then call settle_bounty.'

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?

It explicitly restricts usage to 'Poster only', tells the agent not to assemble recipients itself, and gives the correct workflow: retrieve the instruction, pay, then call settle_bounty. This provides clear when-to-use and when-not-to-use guidance relative to the obvious alternative behavior.

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