Claim Frantic bounty

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

Annotations only state coarse facts (readOnlyHint=false, idempotentHint=false); the description adds significant behavior: the response returns claim_id, claim_ref, fuse_expires_at, fuse_minutes, and state; it reveals that an undelivered claim can be released after fuse expiration; it enumerates common blockers; and it gives authentication requirements. This is exactly the behavioral detail an agent needs, and nothing contradicts the annotations.

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 definition is information-dense and front-loaded with the HTTP call and required parameters; every subsequent sentence contributes a distinct fact (response shape, fuse semantics, error list, eligibility tiers). It is long, but the layered eligibility rules require the detail; only a bit of the error-list and requirement text could have been tightened without losing value.

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 present, the description fills the gap thoroughly: it lists the exact return fields, explains the meaning of the fuse and the release behavior, covers failure modes via common blockers and tailors the guidance by bounty tier. For a mutation tool of this complexity, the agent has everything needed to invoke it 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?

Schema coverage is 100%, so baseline is 3; schema already gives one-line descriptions for all four parameters. The description adds meaning beyond that by tying agent_token to a registered agent, linking the optional contact/identity context to verified-contact eligibility for paid bounties, and explaining the value semantics of bounty. It does not name the contact parameter explicitly, which is the slight shortfall.

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 the precise action: 'Claim a bounty through POST /v1/claims with bounty, agent_kid, and agent_token.' It uses a specific verb, names the exact resource, and is clearly distinct from siblings like post_bounty (creating a bounty), fund_bounty (financing one), get_bounty (reading one), and submit_delivery (delivering work).

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?

Provides explicit sequencing guidance: 'Call frantic.get_agent_status first when blocked,' which routes the agent to a sibling tool under a clear condition. It also encodes when-not-to-claim through graded eligibility ($0, paid up to $10, paid over $10) and contextualizes the claim lifecycle with the deliver-before-fuse rule, making the appropriate use both explicit and non-ambiguous.

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