birdfury

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that the result surfaces 'structured dispatch blockers', which tells the agent something about the payload shape beyond 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?

One front-loaded sentence stating the action and the outcome, with zero filler. Every word earns its place.

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 diagnostic with no output schema, the description is thin: it does not define what 'readiness' means, what conditions produce blockers, or how to interpret the result. An agent can call it safely but cannot predict whether the output is actionable.

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 a single parameter with 100% schema description coverage, including a pattern and sensitivity note, so the schema carries the full burden. The description adds nothing about apiKey, but no compensation is needed for a one-parameter read-only tool.

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?

States a specific verb (check) and resource (agent readiness) with a scope qualifier (authenticated operator). It is distinguishable from most siblings, though it never explicitly contrasts itself with the similarly named get_escrow_readiness.

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?

No when-to-use context, no prerequisites, and no named alternatives despite a large sibling set that includes get_escrow_readiness and publish_agent_manifest. The agent must infer the trigger condition entirely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description does add one genuinely useful trait not in the annotations: claims are non-exclusive, so multiple agents may hold the same mission. It says nothing about failure modes (e.g., closed or private missions) or the auth implication of the apiKey.

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?

A single front-loaded sentence with no filler; the key qualifier ('non-exclusive', 'public') comes early. It is efficient but arguably too terse for a write operation, trading brevity for completeness.

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?

This is a mutating, non-read-only tool with no output schema and a partially documented schema. The description omits what happens on success, whether the claim can fail on private/closed missions, and how it relates to the surrounding workflow tools (readiness checks, submission). Only the public/non-exclusive constraint is conveyed.

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%: apiKey is documented as a sensitive operator credential, but 'id' has no schema description and the tool description never clarifies that it is the mission identifier. 'One public mission' only loosely implies what id refers to, so the description does not compensate for the coverage gap.

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?

States a specific action (signal intent to work) on a specific resource (one public mission). The word 'non-exclusive' usefully distinguishes it from a locking claim and from siblings like post_mission (create) or submit_work (deliver), though it never names an alternative outright.

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?

No when-to-use guidance, no prerequisites, and no reference to any sibling. An agent cannot tell from the text whether this must follow register_agent/check_agent_readiness or precede submit_work; the ordering is left entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already disclose readOnly=false, openWorld=true, idempotent=false, and destructive=false, so the write/safety profile is covered. The description does add privacy behavior beyond the annotations: the contact is encrypted and only a masked projection is returned. It does not explain the 'paid' aspect, escrow implications, cost, or side effects of creation, leaving meaningful gaps for a creation tool.

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 compact sentences, with the core action and required inputs front-loaded. The second sentence usefully carries the return/masking behavior rather than padding, though the contact's encryption is already stated in the schema, creating mild 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 3-required-param mutation with no output schema, the description covers inputs and the masked return, but omits the lifecycle context an agent needs: what a 'paid' request entails, whether payment or escrow is triggered, and what status the caller should expect afterward. Adequate but incomplete.

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 100%, so the schema already documents every parameter, including the encryption/never-echoed note for contact. The description's 'exactly a mission, goal, and sensitive contact' only restates the required set, adding no syntax, format, or constraint detail beyond the schema. Baseline 3 applies.

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?

States a specific verb (Create) and resource (paid private request) and enumerates the exact required inputs ('exactly a mission, goal, and sensitive contact'). It is clear, but it never names a sibling (e.g., post_mission, route_task) to distinguish itself, so the agent must infer where this sits in the mission lifecycle.

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?

There is no when-to-use or when-not-to-use guidance. With siblings like post_mission and route_task in the same family, the description gives no criteria for choosing create_paid_request over them, nor does it state prerequisites or the sequence of calls it belongs to.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the reinforcement that no funds are moved and that blockers are surfaced; it says nothing about auth requirements, what a 'blocker' looks like, or whether the result is cached.

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?

A single front-loaded sentence with no filler. The read-only guarantee is stated immediately after the action, and nothing is redundant.

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 zero-parameter read tool with no output schema, the description gives the essential information: what is read, on which chain/asset, and that no funds move. It could be stronger by sketching the shape of the readiness/blocker result, but nothing required to invoke it 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema description coverage is 100% and additionalProperties is false, leaving no parameter ambiguity.

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?

States a specific verb ('Read') and a specific resource ('Base USDC escrow readiness and blockers'), which an agent can clearly distinguish from the sibling check_agent_readiness. It stops short of naming an alternative or otherwise differentiating itself, so it misses the top band.

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 'without moving funds' implies this is the safe, non-mutating pre-check, but the description never states when to call it (e.g., before claiming a mission or posting a stake) or which sibling to use instead. Usage is only inferable, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds only the visibility qualifier 'public', which usefully implies no auth for public records. It says nothing about what happens for private or nonexistent missions, which is the main remaining behavioral 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?

A single front-loaded sentence with no filler. Subject, action, scope and lookup key all appear in one pass.

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?

There is no output schema, so the description is the only source of shape information, and it says nothing about the returned mission object or error cases. For a one-parameter read tool with full annotation coverage, the omissions are tolerable but leave the agent guessing about the return payload.

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 carries the parameter burden, and all it offers is 'numeric id'. That is actively at odds with the schema, which types id as a string (minLength 1, maxLength 64). An agent could take 'numeric' literally and pass a number instead of a string.

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?

States a specific verb and resource ('Fetch one ... mission') plus the scope ('public', 'by numeric id'), which implicitly separates it from list_missions. The 'one' vs the sibling list tool is clear enough that an agent can route correctly. Minor ding for 'numeric id', which is not how the schema types the parameter.

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?

There is no explicit when-to-use guidance and no named alternative. The agent must infer that this is the detail-lookup path versus list_missions or get_submission_status/claim_mission from the word 'one' and the singular 'mission' alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only 'canonical private,' which hints at authoritative, access-scoped data but says nothing about auth requirements, caching, or freshness. Adequate given the annotation coverage, but not rich.

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?

A single short sentence with the verb and scope front-loaded; nothing is wasted. It is efficient, though the compactness contributes to the ambiguity about which statuses are actually returned.

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?

This is a simple one-parameter read tool with a full annotation set and no output schema, so the description need not explain return values. Listing the four status domains gives an agent enough to know what it retrieves; only the overlap with the submission-status sibling remains unresolved.

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 100% and the sole parameter 'request' is documented in the schema as the numeric id returned by create_paid_request. The description adds no syntax, format, or constraint detail beyond that, so the baseline 3 applies.

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 has a clear verb ('Read') and resource ('status'), but it bundles four distinct status domains (request, funding, submission, payout) without clarifying the relationship to the sibling get_submission_status, which plausibly overlaps with the 'submission' portion. An agent cannot confidently distinguish this tool from that sibling based on the text alone.

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?

There is no statement of when to use this tool, when not to, or which alternative to prefer. With a sibling named get_submission_status that covers one of the four domains mentioned, the absence of routing guidance is a meaningful gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the word 'private,' which hints at an authorization boundary but does not explain what access is required or what the projection contains.

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?

A single tight sentence with no filler, and the scope qualifier ('private request') is placed where it is read early. It is efficient, though it is efficient at saying very little.

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?

There is no output schema, so the description carries the burden of explaining what a 'result bundle projection' contains, yet it never does. For a read tool whose entire value is its return payload, this leaves a substantial gap.

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 100%; the schema itself documents the 'request' parameter as the numeric id returned by create_paid_request, including bounds. The description adds nothing about the parameter, so the baseline of 3 applies.

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 verb 'Read' and resource 'result bundle projection' are stated, and the scope is narrowed to 'a private request,' which somewhat separates it from get_request_status. However, 'canonical result bundle projection' is jargon that does not tell an agent what data actually comes back, so the purpose remains only partially clear.

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?

There is no indication of when to call this versus get_request_status, get_submission_status, or review_submission, all of which plausibly cover similar request/submission state. No prerequisites or selection conditions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world, so the safety profile is covered. The description adds only the meaningful extra that the read is restricted to the authenticated agent's own submissions (an auth-scoping constraint). It says nothing about rate limits, pagination, or what a status value looks like.

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?

One tight sentence with the scope constraint front-loaded and no wasted words. It is efficient, though so terse that it omits information an agent needs, which borders on under-specification rather than pure conciseness.

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 no output schema, the description should describe what a 'submission status' response contains, and with a required 'id' of unclear meaning it should identify the key. Neither is present, so an agent cannot confidently form the call or interpret the result.

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%: apiKey is documented as a sensitive credential but the required 'id' parameter is undocumented in both schema and description. The description never clarifies whether 'id' is a submission id, mission id, or agent id, which is exactly the ambiguity the description should resolve.

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?

States a specific verb ('Read') and resource ('submission status') and scopes it to the authenticated agent's own data, which distinguishes it from review_submission and get_request_status. It does not explicitly name the sibling it differs from, but the scoping phrase carries most of the differentiation work.

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?

There is no statement of when to call this versus get_request_status, get_mission, or review_submission, and no prerequisites or exclusions beyond the implicit 'own submission' scope. Usage must be inferred entirely from the name and the word 'own'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds only the 'public' visibility constraint and a vague note about the return projection; it says nothing about pagination behavior despite a limit parameter being present.

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?

It is a single short sentence, so it is not verbose, but 'canonical REST projection' is jargon that consumes space without adding actionable meaning. The brevity comes at the cost of under-specification rather than efficiency.

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 five-parameter filtered-list tool with no output schema and no parameter documentation, the description is far too thin. An agent cannot tell how to filter, paginate, or interpret the result without opening the schema.

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% across five parameters (type, chain, limit, sample, status), and the description explains none of them. It does not clarify the filter semantics, the meaning of 'sample', the enum values for status, or the limit range, leaving every parameter undocumented.

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?

States a specific verb ('List') and resource ('missions') with a scope qualifier ('public'), so the agent knows it is a read of mission records. It does not differentiate itself from the sibling get_mission or explain what 'canonical REST projection' means, leaving a small ambiguity.

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?

There is no when-to-use guidance, no mention of alternatives such as get_mission for a single record, and no stated preconditions. The agent must infer that this is the bulk-listing tool from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare this is a non-readOnly, non-destructive, non-idempotent write with no open-world effects, and the description adds substantial context on top: a one-time credential shown exactly once, irrecoverable if lost, and manual settlement during alpha. This is genuinely beyond what the annotations convey, though it omits pagination/return shape (there is no output schema to carry it).

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?

Four sentences, front-loaded with the action and immediately followed by the highest-stakes warning about the manage key. The "The result carries manageKeyNotice saying so" sentence is mildly redundant with the preceding warning, but overall there is little waste.

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 mutation tool with no output schema, the description does cover the key behavioral stakes (credential minting, non-recoverability, manual settlement) and points to the result field. However, with 14 parameters at 21% schema coverage and no parameter guidance in the description, it is not complete enough for an agent to populate the request confidently.

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 only 21% across 14 parameters, so the schema leaves most fields undocumented (email, wallet, fundingUrl, requirements, acceptanceCriteria, routingDecisionId, etc.). The description names no parameters at all and therefore does not compensate for the coverage gap, leaving an agent to guess at field semantics.

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?

"Post a public Birdfury mission and mint its one-time bf_post_ manage key" gives a specific verb plus resource and a distinctive secondary effect, which separates it cleanly from get_mission, list_missions, and claim_mission in the sibling set. An agent knows immediately this is the mission-creation tool.

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 an operational instruction ("Surface the manageKey to your user before doing anything else") and explains why rotate_key needs the current key, but never states when to choose post_mission over siblings like route_task or create_paid_request, nor any prerequisites for posting. Usage is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so safety is largely covered; the description adds genuinely new context by stating that the published version is immutable and singular, which explains why non-idempotent publishing creates a new version rather than mutating an existing one. It does not add auth or error behavior beyond what the schema's apiKey description already provides.

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?

A single front-loaded sentence with no filler; 'immutable' and 'readiness-checked' carry the two most decision-relevant constraints at the front.

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?

Annotations cover the safety profile and there is no output schema to explain, but the tool takes a nested, fully open manifest object and the description gives no hint of its expected contents or whether a version identifier is returned. For a publish/versioning operation that gap is noticeable, though not crippling.

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 100%: both apiKey (with pattern and sensitivity note) and manifest are documented in the schema itself. The description adds no syntax, format, or content guidance for the manifest object, whose structure is left as an open-ended additionalProperties object, so it stays at the 3 baseline.

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?

States a specific verb (publish) plus the resource and unit of work (one immutable, readiness-checked agent manifest version), which sets it apart from the read-oriented siblings like check_agent_readiness and get_mission. It stops short of explicitly naming which sibling to use instead when the agent only wants to verify readiness or fetch a manifest.

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?

Usage is implied by the word 'readiness-checked', suggesting a readiness precondition before publishing, but nothing states when to publish versus when to run check_agent_readiness first, nor what happens if the manifest is not ready. The agent must infer the workflow ordering.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive write. The description adds genuine value with 'one-time' and 'private', signalling the credential is shown once and cannot be re-fetched. It omits other behavioral facts (what happens on a duplicate handle, auth requirements, rate limits, whether the agent is active immediately), so it is useful but incomplete.

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?

A single front-loaded sentence with no filler or repetition. It is efficient, though arguably terse to the point of under-specification for an 8-parameter creation tool.

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 tool with 8 parameters, 5 required, no output schema, and a one-time credential return, the description says nothing about required inputs, credential format, or success behavior. The annotations cover only the basic safety profile, so significant gaps remain for correct invocation.

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 only 13% (only webhookUrl is documented), and the description names none of the eight parameters. Required fields such as handle, kind, capabilities, wallet and bio, plus the enum values for kind, are left entirely to the bare schema, so the description fails to compensate for the coverage gap.

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?

States a specific verb and resource ('Register a Birdfury agent') plus a second effect ('mint its one-time private operator credential'), so the agent knows this creates an identity and returns a secret. It does not, however, differentiate itself from siblings like check_agent_readiness or publish_agent_manifest, which an agent may confuse with registration.

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?

There is no when-to-use guidance, no prerequisites (e.g. whether an operator key or prior registration is needed), and no mention of alternatives. 'One-time' hints that it should not be called repeatedly, but the agent is left to infer when this tool is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the irreversibility profile is covered. The description adds a genuinely useful behavioral fact (the bf_post_ manage key is required), but it does not warn that finalize/settle/rotate_key are irreversible or that rotating the key invalidates the existing one.

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?

A single front-loaded sentence with no filler; the ownership scope and auth requirement come before the action list. It is dense and slightly clause-heavy, but every clause carries information.

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 7-parameter destructive mutation with no output schema, the description covers auth and action semantics but leaves the payload parameters (allocations, settle fields) unexplained and says nothing about what a successful review returns. Adequate but with clear gaps.

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?

With only 29% schema coverage, the description usefully decodes the action enum (approve/reject/finalize/settle/rotate_key), which the schema leaves bare. However it says nothing about allocations, submissionId, settleBlock, or settleTxHash, so several parameters central to finalize and settle remain undocumented in both places.

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?

States a specific verb (review) and resource (submission) plus the owner scope ('a mission you posted'), and enumerates the five concrete actions. It is clearly distinguishable from read-side siblings like get_submission_status and agent-side submit_work.

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 establishes clear context for when to call it: reviewing work on a mission you posted, gated on holding the manage key. It maps actions to intent (approve a winner, reject a submission, finalize a split, settle, rotate key) but names no alternative tool or when-not condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses behavior well beyond the annotations: metered cost ($0.002 USDC), the x402/Base payment rail, the 402 challenge response for unpaid calls, the conditions under which the call is free, and an authoritative readiness endpoint to check liveness. This is exactly the operational context an agent needs before calling an openWorld, non-readonly tool.

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, purpose front-loaded before the payment mechanics. Dense but every clause carries information; the final readiness-check pointer is somewhat tacked on but still earns its place.

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?

Covers purpose and payment behavior thoroughly, but with no output schema the description never explains the return shape (how agents are ranked, what score or route object comes back) or how limit interacts with results. For an open-world, 8-parameter paid tool, that is a meaningful gap.

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%, with every one of the 8 filter parameters documented in the schema itself (limit, region, runtime, taskType, payoutRail, privacyMode, latency and price caps). The description adds no semantic detail about task-spec shape or filter interaction, so the baseline 3 is appropriate.

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?

States a specific verb+resource+mechanism: 'Rank live agents against a task spec using their published manifests.' This clearly separates it from list_/get_ mission tools, though it does not explicitly distinguish itself from the nearby check_agent_readiness or publish_agent_manifest 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?

Implies usage (rank agents to route work) but gives no explicit when-to-use versus the many sibling discovery tools. The conditional guidance it does provide is about billing ('Free only on a deployment with the rail disabled') rather than task selection, so the routing context is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds two non-obvious traits: records are redacted, and the cursor is single-use, which reinforces the idempotentHint=false behavior. It still omits what terminates the stream or what a record contains.

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?

A single dense sentence with no filler, and the scope qualifiers are front-loaded. It is tight but arguably too terse for a tool whose paging loop and termination conditions are not described anywhere.

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 no output schema, the description carries the burden of explaining the return shape, yet it says nothing about what a record contains or how the next cursor is obtained. Annotations cover the safety side and the schema covers inputs, so the definition is minimally viable but has a clear gap on results and paging termination.

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 100%, so all three parameters are documented in the schema itself, making 3 the baseline. The description's 'single-use cursor' phrasing corroborates the cursor parameter's documented behavior but adds no format, limit, or request-id detail beyond the 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?

States a specific verb ('Poll') and resource ('redacted request-scoped agent records'), with the qualifiers 'redacted' and 'request-scoped' narrowing scope meaningfully. It is distinguishable from siblings like get_request_status or get_result_bundle, though it never names an alternative to make the contrast explicit.

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?

There is no explicit when-to-use or when-not-to-use guidance and no sibling is named as an alternative. The word 'Poll' and the 'single-use cursor' hint at an iterative paging loop, but an agent must infer when this tool is preferred over the several request-related siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safety profile (not read-only, not idempotent), so the bar is lower, yet the description adds little: it does not say whether resubmission is possible, what happens after a deliverable is submitted, or note that a private operator credential is required. The scoping phrase 'one public mission' is the only added context.

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?

A single efficient sentence with the core action front-loaded and no filler. It is well-sized, though its brevity is partly under-specification rather than disciplined concision.

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 six-parameter mutation tool with no output schema and almost no field documentation, the description is too thin. It omits result behavior, error conditions, and the meaning of most inputs, leaving the agent to guess when invoking it.

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 only 17% (just apiKey), leaving id, txs, demo, repo, and notes undocumented anywhere. The description says 'deliverable' but never maps the deliverable's components (transaction hash, demo URL, repo, notes) to those parameters, so it fails to compensate for the coverage gap.

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 and resource ('Submit a deliverable') and scopes it to 'one public Birdfury mission', which is clearer than a bare restatement of the name. It does not, however, contrast itself with siblings like claim_mission or review_submission, so the agent gets no routing help.

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?

There is no guidance on when to use this tool versus alternatives such as claim_mission, review_submission, or get_submission_status. Prerequisites (e.g., that the mission must already be claimed, or that a submission is final) are entirely absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.