Claim a bounty from get_bounties. wallet = an EVM address (0x + 40 hex) that can hold USDC on Base. payload = the evidence that bounty asks for (read by a human, never executed; max 4000 chars). Returns claim_id + status_url. Turnaround: days.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | ||
| payload | Yes | ||
| bounty_id | Yes | ||
| sender_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that wallet must be an EVM address on Base, that payload is read by a human and never executed, caps payload at 4000 chars, and indicates turnaround time in days. This is strong behavioral context, though it does not cover side effects or reversibility.
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 well-structured: purpose first, then parameter definitions, then return values and turnaround. Every sentence adds useful information without repetition or filler.
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 and no annotations, the description covers the core concerns: what the tool does, how to format the main parameters, what is returned, and expected timing. It could be more complete by explaining how to use claim_id/status_url or clarifying sender_name, but it is largely sufficient for an agent to call the tool 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 description coverage is 0%, so the description must compensate. It adds meaningful semantics for wallet and payload, including formats and constraints. However, bounty_id and sender_name are left entirely to their schema titles, so the description only partially compensates for the low coverage.
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: 'Claim a bounty from get_bounties.' It clearly identifies the action and the source of bounty data, and the 'Returns claim_id + status_url' clause distinguishes it from browsing bounties or checking a claim.
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 phrase 'from get_bounties' gives clear context that this tool is used after listing bounties, and the mention of returning a status_url implies later status checking. It does not explicitly rule out alternatives like check_bounty_claim, but the usage context is reasonably clear.
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.
Every tool targets a distinct resource or action: bounties are list/claim/check, card composition is template/offer/phrase selection, and send_card is clearly separated from send_sample_card and preview_card. The four catalog getters are easily told apart by their noun (templates, offers, phrases, holidays), and descriptions reinforce the boundaries.
All tools follow a consistent snake_case verb_noun pattern: get_* for listing, send_* for delivery actions, preview_card for dry-run, and submit/check for bounty workflow. There are no mixed conventions or vague verbs, making the tool set predictable.
Ten tools is well within the ideal range and each tool earns its place. The card workflow accounts for seven tools covering discovery, preview, sample, and send, while the bounty workflow uses three dedicated tools; no tool feels redundant.
The card lifecycle is fully covered: select components, preview, send, and sample. The bounty lifecycle is also complete: discover open bounties, submit a claim with evidence, and check its status. There are no obvious dead ends or missing core operations for the stated domain.