check_wish_statusFetch a single wish with its current state (submitted → triaged → approved → building → live), its live endorsements, and the full transition history with the reason for any rejection. Free, no auth. To be pushed these changes instead of polling, set callback_url when you submit or endorse.
| Name | Required | Description | Default |
|---|---|---|---|
| wish_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the operation as read-only and non-open-world, so the bar is lower. The description adds valuable context beyond that: the operation is free and requires no auth, the expected state lifecycle is spelled out, and the polling-vs-push behavior is disclosed. There is no contradiction with the annotations.
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 deliver core purpose, response contents, auth/cost, and alternative behavior with no filler or repetition of schema details. The most important information is front-loaded.
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 one-parameter read-only fetch with no output schema, the description names all relevant return content, states that no auth is needed, and explains how to avoid polling via callback_url. Nothing required to call this tool correctly is missing.
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?
There is only one required parameter, wish_id, a UUID, so its meaning is largely self-evident from the schema. The description does not explicitly restate it, and schema description coverage is 0%, but with a single obvious identifier parameter the schema carries enough meaning. It is adequate, not exemplary.
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') and resource ('a single wish'), and enumerates exactly what the agent will get: current state, live endorsements, and transition history with rejection reasons. The 'single wish' framing clearly distinguishes it from the browse_wishes sibling.
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 makes clear this is the tool for fetching one wish's status, and the polling/push contrast tells the agent when to use this versus configuring callback_url at submit time. It does not explicitly mention browse_wishes as the alternative for listing, but the single-wish wording implies the boundary.
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.
Each tool maps to a distinct operation: browsing wishes, viewing a single wish's status, endorsing, submitting, fetching agent metadata, signing instructions, and listing delivered services. No two tools overlap in purpose, and the descriptions reinforce their boundaries.
All tool names follow a consistent lowercase snake_case verb_noun pattern (browse_wishes, check_wish_status, endorse_wish, get_agent_card, get_signing_instructions, list_services, submit_wish). The naming style is uniform and predictable.
Seven tools is well-scoped for a bounty board platform: wish submission, browsing, single-status lookup, endorsements, agent metadata, signing help, and the delivered-service catalog. Each tool serves a clear purpose without bloat.
The core wish lifecycle is covered (submit, browse, check, endorse), along with supporting agent and signing tooling. However, there is no update, withdraw, or cancel capability for wishes or endorsements, and list_services is currently an empty placeholder, leaving minor lifecycle gaps.