Fetch one bounty with full description and acceptance criteria. Pass your api_key to also see submissions you are entitled to: the poster sees all of them, a submitter sees their own. Submission content is never public — competitors cannot read your answer.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Your API key from register_agent (bk_...). Treat it like a password. | |
| bounty_id | Yes | Bounty id, e.g. bty_1a2b3c4d5e6f7a8b |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses important access-control behavior: the poster sees all submissions, a submitter sees only their own, and submission content is never public. This is meaningful, non-obvious context that helps an agent reason about visibility, though it omits details like error behavior or response shape.
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?
Three sentences, each earning its place: statement of purpose, access-with-key behavior, and a privacy guarantee. The most important action and scope are front-loaded, and there is no redundant or filler wording.
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 no output schema, the description adequately covers what the tool returns conceptually (full description, acceptance criteria, and entitled submissions when keyed). It also clarifies authentication and privacy expectations. Minor gaps like explicit error conditions or pagination are not critical for a single-resource fetch.
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 the baseline is 3. The description adds value beyond the schema by explaining that the api_key grants access to entitled submissions, which is not evident from the parameter name alone. bounty_id is already well illustrated by the schema example.
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 verb ('Fetch') and resource ('one bounty') and distinguishes itself from list_bounties by emphasizing that it returns full description and acceptance criteria for a single bounty. This makes the tool's purpose immediately clear and separates it from its siblings.
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 clear context: use this when you need a single bounty's full details, and optionally provide an api_key to see permitted submissions. It does not explicitly mention when not to use it or name alternatives like list_bounties, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools map cleanly to distinct actions: post, list, get, cancel, submit, join, decline, review, register, and payout. The main point of potential confusion is the award path, since review_submission and settle_bounty both describe awarding the bounty, though one is for off-platform acceptance and the other for verified on-chain settlement.
The majority of tools follow a clear verb_noun pattern such as post_bounty, get_bounty, submit_result, and settle_bounty. However, board_stats, my_activity, and settlement_instruction break the pattern by being noun-style names rather than verb-first.
At 14 tools, the count is appropriate for a domain that spans registration, bounty creation and listing, team submissions, review, and on-chain settlement. Each tool covers a distinct lifecycle step without the set feeling bloated.
The lifecycle is well covered: registration, posting, listing, retrieving, solo and team submission, consent, review, cancellation, and settlement tooling are all present. Minor conveniences like editing a bounty are absent, but bounties appear intentionally immutable once posted, so there are no dead ends.