Review work on a mission you posted: approve one winner, reject one submission, finalize a multi-winner split, record a payout tx (settle), or rotate the manage key. Requires the mission's bf_post_ manage key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The mission's public numeric id. | |
| action | Yes | ||
| manageKey | Yes | Sensitive bf_post_ mission manage key — shown once at post time. | |
| allocations | No | ||
| settleBlock | No | ||
| settleTxHash | No | ||
| submissionId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. It does mention the sensitive key requirement and lists mutating actions like settle and rotate_key, but it does not disclose whether actions are irreversible, whether approving one winner auto-rejects others, or what the result of each action looks like. This is a moderate gap.
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 precisely two sentences, with the primary purpose front-loaded and the auth requirement in a short second sentence. Every word serves a purpose, and there is 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?
With 7 parameters, no output schema, and no annotations, the description covers purpose and auth but omits return values, inter-action constraints, and postconditions (e.g., whether approval finalizes the mission or if reject is final). It is sufficient for a basic understanding but leaves operational details to inference.
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 only 29% (2/7 params described), so the description must compensate. It effectively explains the core 'action' parameter by enumerating the five enum values in plain language ('approve one winner, reject one submission, finalize a multi-winner split, record a payout tx, rotate the manage key'). It also contextualizes allocations and settle fields, adding meaning beyond the raw schema.
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+resource ('Review work on a mission you posted') and enumerates the distinct actions (approve, reject, finalize, settle, rotate key), making it clear what the tool does. This also differentiates it from sibling tools like get_submission_status or submit_work by listing the review-specific operations.
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?
It states a clear prerequisite ('Requires the mission's bf_post_ manage key') and the context ('on a mission you posted'), which tells the agent when this tool is appropriate. It does not explicitly mention when not to use it or name alternative tools, but the context is unmistakable for a poster reviewing submissions.
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 distinct purposes, but there is potential confusion between status/readiness getters (check_agent_readiness vs get_escrow_readiness, get_request_status vs get_submission_status) and between create/post/publish verbs.
Uses consistent snake_case with verb_noun structure, but mixes synonyms for similar actions (get/check, create/post/publish), making the pattern less predictable.
16 tools is slightly above the ideal 3-15 range, but each tool addresses a distinct aspect of the mission/agent/escrow lifecycle, so it feels well-scoped rather than bloated.
The core mission lifecycle (post, submit, review) and agent registration are covered, but there are gaps: no update/delete for missions or requests, no explicit funding tool for paid requests, and no general agent listing.