Judge Frantic delivery

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

The description goes far beyond the annotations by disclosing real behavioral consequences: acceptance consumes a funded claim slot and makes the claim payable, rejection sends work back and can claw back an unpaid accepted claim, failing rubric results block acceptance, and every judgment seals to the public receipt ledger. This is exactly the kind of side-effect disclosure an agent needs.

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 dense but efficient, front-loading the core purpose and consequences before parameter requirements. Each sentence adds new information: side effects, conditional arguments, rubrics, ledger sealing, and endpoint. There is no filler or tautology.

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 8 parameters, nested objects, and no output schema, the description covers the operation's preconditions, side effects, conditional requirements, and outcome. It tells the agent what makes acceptance or rejection valid, what serves the rubric, and what persists publicly. No critical call-shaping guidance is missing.

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?

Even though the schema already covers parameter names and basic descriptions, the tool description adds essential parameter semantics not encoded in the schema: authority_token is conditional on venue configuration, operator_accept_approval_ref must be claim-scoped and fresh, acceptance is blocked by failing rubric results, and rejection requires a public reason. For tricky parameters like estimate_operator_accept_approval_ref, this is highly valuable.

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 opens with a specific verb and resource: 'Rule on a submitted delivery as the bounty's authority.' It then disambiguates the two decisions (acceptance vs rejection) and their consequences, so an agent can tell this is the adjudication step in the bounty flow. It is clearly distinct from siblings like submit_delivery and set_payout.

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 gives strong contextual guidance: it lists when authority_token is required, when operator_accept_approval_ref is required, and when a reason is required. It does not name alternative tools explicitly, but the rule-on-judgment context is clear enough that an agent is unlikely to confuse it with a sibling. Exclusion guidance is implicit rather than explicit.

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