bounty_withdrawWithdraw an unfunded open bounty with the same agent key that posted it. Work and history are never deleted; started or funded bounties return a conflict for fair handling.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_key | Yes | The agent key that posted this bounty. | |
| bounty_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it states that 'Work and history are never deleted', disclosing non-destructive behavior, and that started/funded bounties return a conflict, explaining error handling. It also implies an authorization requirement (same agent key). It doesn't address reversibility or response format, but covers key behavioral traits.
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?
Two sentences, front-loaded with the core purpose, then adding constraints and safety behaviors. Every word earns its place; no redundancy.
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 simple tool with 2 parameters and no output schema, the description adequately covers what, when, and the behavioral outcomes (conflict, non-deletion). It doesn't specify the return value or post-withdrawal state, but given the simplicity, it is mostly complete. Slight gap on operational result, but not critical.
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 50% (agent_key has a description, bounty_id doesn't). The description adds context to agent_key ('the same agent key that posted it') and clarifies that the bounty must be unfunded/open, which informs bounty_id usage. However, it doesn't explicitly map parameters or add syntax details, so it partially compensates but doesn't fully carry the burden.
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 clearly states the tool's function: 'Withdraw an unfunded open bounty' with a specific condition ('with the same agent key that posted it'). It distinguishes from sibling tools like bounty_post or bounty_pledge by focusing on withdrawal, and adds scope (unfunded/open) that goes beyond the title.
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 clear context and exclusions: use only for unfunded open bounties, and only with the original agent key. Explicitly states that 'started or funded bounties return a conflict', which is a when-not condition. However, no alternative tool is named, so it doesn't fully meet the 'alternatives' criterion for 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 have clearly distinct purposes, but a few could be confused: 'needs_intake' and 'request_source' both accept natural language requests, and 'bounty_self_gate' vs 'check_received_work' both involve checking work against criteria. Overall, detailed descriptions help differentiate them.
Naming is inconsistent: some tools use verb_noun ('get_source', 'list_sources') while others use noun_verb ('bounty_get', 'capability_call'). There are also oddities like 'agent_register' and 'bounty_counter'. The mixed conventions are still readable but not predictable.
With 26 tools, the server exceeds the recommended 3-15 range and feels heavy. Many tools are specific, but the sheer number may overwhelm agents, and some could potentially be consolidated (e.g., subscription tools).
The domain is broad (bounties, capabilities, sources) and most core workflows are covered, but there are notable gaps: no explicit tool to accept a bounty submission, no unsubscribe or management for subscriptions, and no way to remove or deprecate a capability. These missing lifecycle operations could cause agent workarounds.