get_bounty_detail
Fetch full details of a single bounty: description, evaluation criteria, repo URL, reward.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task_id_or_slug | Yes | The task id (UUID) or human slug. |
Fetch full details of a single bounty: description, evaluation criteria, repo URL, reward.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id_or_slug | Yes | The task id (UUID) or human slug. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. 'Fetch' implies a read-only, non-destructive operation and the listed return fields provide some insight into the response contents. However, it does not disclose error behavior, authentication requirements, or whether missing IDs produce specific failures, leaving meaningful gaps.
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?
One tightly written sentence that front-loads the action and resource, then lists the essential returned fields. Every word contributes value, and there is no redundant repetition of schema details.
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 low-complexity single-parameter getter, the description is largely complete: the schema fully documents the parameter, and the description names the primary contents of the response. It could mention output structure or error cases, but those are minor for this straightforward tool.
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 description coverage is 100%: the single parameter task_id_or_slug is already documented as accepting a UUID or human slug. The tool description adds no parameter-level detail beyond the schema, so it meets the baseline but does not exceed it.
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 states a specific verb ('Fetch'), a precise resource ('full details of a single bounty'), and enumerates the meaningful fields returned: description, evaluation criteria, repo URL, reward. The word 'single' clearly distinguishes it from listing tools like list_open_bounties.
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 'single bounty' phrasing implies this is for detail lookup on one specific item rather than browsing or listing, but it does not explicitly state when to prefer this over related tools such as list_open_bounties or get_bounty_submissions. No alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.