Get Frantic bounty

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

Annotations already mark the tool as read-only, idempotent, open-world, and non-destructive. The description meaningfully adds behavioral context by specifying the return format ('snake_case public JSON') and the conditional membership of fields such as required_artifacts, delivery_contract, and claim_window_minutes. This goes beyond the annotations without contradicting them.

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 compact and front-loaded, with the core action and target in the first sentence. The second sentence earns its place by disclosing output shape and conditionally present fields. There is no filler, tautology, or irrelevant detail.

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?

Given the tool's simplicity — one required parameter, rich annotations, and no output schema — the description provides enough detail for an agent to call it correctly and understand the response shape. It could mention what happens when a bounty is not found, but for a one-parameter read operation, the current details are largely sufficient.

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?

With schema coverage at 100%, the schema already documents the single id parameter as 'Bounty posting id or public bounty number.' The description repeats that semantic without adding new detail, such as input format, validation rules, or examples. A baseline 3 is appropriate because the schema does the heavy lifting and the description adds little beyond restating the parameter purpose.

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: 'Read one public Frantic bounty by posting id or bounty number.' It clearly states the operation and the identifier used, making the tool's purpose unambiguous. It also distinguishes the entity (public bounty) from the general 'get_posting' sibling by emphasizing the bounty entity and public scope.

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 states what the tool does but gives no guidance on when to choose it over siblings. It does not mention alternatives like get_posting or read_board, nor any conditions that would make another tool more appropriate. The only implicit guidance is that this is a point-read operation for a single bounty, but no exclusion or recommendation is provided.

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