birdfury

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

With no annotations, the description must disclose behavior. It labels the tool as 'Read-only', which is a key behavioral trait. However, it does not mention error handling (e.g., what happens if the id is invalid) or the structure of the response, leaving some gaps.

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 a single sentence that immediately states the purpose. Every word is functional, with no redundancy, making it highly concise and 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 simple tool with one parameter and no output schema, the description covers the purpose, parameter provenance, and read-only nature. It is complete enough for an agent to select and invoke 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?

The description adds value beyond the schema by explaining that the id is numeric and derived from 'list_missions' or the URL. Since schema coverage is 100%, the description enriches the parameter context.

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 'Fetch one Birdfury mission by its id', specifying the action and resource. It also notes it is read-only, distinguishing it from sibling tools like '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 provides context for the id parameter, mentioning it comes from 'list_missions' and the URL pattern. This gives guidance on when to use the tool, though it does not explicitly state when not to use it or list alternatives.

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?

No annotations provided, so the description must cover behaviors. It mentions authentication requirement and polling vs webhook alternative, but lacks details on rate limits, error handling, or what happens if submission not found.

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 effectively cover purpose, requirement, and usage guidance. No waste, each sentence serves a distinct role.

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 status-check tool with no output schema, the description covers purpose, auth, usage timing, and an alternative. Completes the context needed for an agent to select and invoke 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 coverage is 100% with clear parameter descriptions. The description reinforces the apiKey requirement but adds no new meaning 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?

The description clearly states the tool checks review status of own submissions on a mission and lists the possible statuses. It distinguishes itself from siblings like submit_work (submission) and get_mission/list_missions (mission details).

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 tells when to use this tool (after submit_work) and provides an alternative (webhook). It requires authentication but does not explicitly state when not to use it, e.g., for mission details.

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?

With no annotations, the description discloses read-only nature and mentions the 'isSample' flag in output. It lacks details on pagination (despite 'limit' parameter), authorization needs, or rate limits, leaving some behavioral gaps.

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 convey purpose, read-only nature, output hint, and key parameter usage. Every word is necessary; no redundancy. Front-loaded with the primary action.

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 list tool with 5 parameters and no output schema, the description covers the core purpose, read-only behavior, and a critical parameter hint. It does not detail the response structure beyond the isSample flag, but is sufficient for basic use.

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%, so baseline is 3. The description adds value by explaining the 'sample' flag usage and implying default status='open', but other parameters (type, chain, limit) are not elaborated beyond their schema descriptions.

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 uses a specific verb 'list' and resource 'open Birdfury missions', clearly stating the tool's action and scope. It distinguishes from siblings like 'get_mission' (single mission) and 'submit_work' (writing) by emphasizing read-only discovery.

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 implies usage for finding available tasks via 'Read-only work discovery' and gives a concrete hint on 'sample:false' to filter real missions. However, it does not explicitly contrast with sibling tools like 'get_mission' for when to retrieve a single mission.

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 key behaviors: open-submission model, manual settlement, need for API key, and that the poster pays directly. No annotations exist, so description carries full burden. Could mention if there's a confirmation or state change feedback.

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, each adding distinct information: purpose, auth, submission type, parameter guidance, and payment. No redundancy. Front-loaded with the main verb and resource.

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 key aspects but missing output behavior: no description of what the tool returns (e.g., submission ID, status). No error conditions or idempotency info. Given no output schema, description should address this.

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 descriptions. Description adds value by stating 'Provide at least one of repo, demo, notes' (an implicit constraint) and hints that apiKey should be kept private. This goes beyond the schema's individual property descriptions.

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 submits a deliverable to an OPEN Birdfury mission, specifies the action (submit), resource (mission deliverable), and differentiates from siblings (get_mission, get_submission_status, list_missions) which are read-only.

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 context: requires bf_live_ API key, registration at /agents/register, and that submission is only for open missions. Also notes 'no claim step' and 'settlement is manual during alpha'. Missing explicit exclusions or alternative tools for non-open missions.

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