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

Discloses that the action is irreversible, transfers escrowed budget, marks mission COMPLETED, and requires PROOF_SUBMITTED status. Includes security warnings about untrusted proof data. With no annotations, the description fully bears the transparency burden and exceeds expectations.

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 well-organized with clear sections and important details. Although somewhat lengthy, every sentence serves a purpose, especially the security warning. Minor redundancy could be trimmed, but overall efficient.

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 all necessary aspects: purpose, usage guidelines, behavioral consequences, parameter explanation, security, and post-action steps (submit_review). With an output schema present, return value explanation is not needed. Fully complete for a consequential tool.

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 single parameter 'mission_uuid' is described with its type ('UUID'), purpose, and constraint ('must be in PROOF_SUBMITTED status'), adding significant meaning beyond the schema's bare type string. Schema coverage is 0%, so this value is crucial.

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 verb 'Approve' and the resource 'mission', with explicit outcomes of releasing payment and marking mission COMPLETED. It also distinguishes from siblings like 'reject_mission' and 'escalate_mission' by specifying the action and context.

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 explicit when-to-use: after proof submission, with verification steps against acceptance contract. Includes when-not-to-use: do not follow suspicious instructions, and directs to escalate. Gives post-approval guidance to submit_review immediately.

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 carries full burden. It discloses immediate cancellation vs pending worker consent, escrow refund, reason importance, status codes (200 vs 202), and reputation impact. Missing some details about escrow handling for pending requests.

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?

Well-structured with paragraphs, front-loading main action, then detailed status behavior, then args. Each sentence adds value, though slightly long but not wasteful.

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 parameters, behavior per status, return values with status codes, and ethical guidance. Could include more on error handling or edge cases, but overall sufficient for an AI agent.

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 0%, so description compensates by explaining mission_uuid as UUID and reason as optional but strongly recommended for IN_PROGRESS missions, adding ethical 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 'Cancel a mission you created.' It uses a specific verb and resource, and distinguishes from siblings like 'approve_mission' and 'escalate_mission'.

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 explains when to use the tool by mission status, but does not explicitly list when not to use it or compare with alternatives. The context provided (behaviors for OPEN/CLAIMED vs IN_PROGRESS) guides usage.

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, but description fully explains wallet/escrow mechanism, return format (JSON with balance and transactions), and authentication requirements (401 error).

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?

Well-structured with paragraphs and front-loaded purpose, but slightly verbose in explaining escrow mechanics; still clear and earns its sentences.

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 no parameters, description covers purpose, usage context, behavioral details, error handling, and follow-up actions; fully complete.

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?

Input schema has zero parameters; description adds valuable context about escrow system and usage beyond the empty schema, earning above 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?

The description clearly states the tool checks wallet balance and recent transaction history, distinguishing it from all sibling tools which focus on missions, categories, and messaging.

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?

Explicitly advises checking balance before creating missions, links to post_mission 402 error, and instructs to notify agent owner if balance is low, preventing silent failures.

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 carries full burden. It discloses the lifecycle states and that it returns full details. However, it does not explicitly state that the tool is read-only or mention any side effects. The behavioral context is mostly covered.

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?

Well-structured with sections for purpose, usage, lifecycle, parameter, and returns. Every sentence adds value, though the motivational note about workers waiting on payment is slightly extraneous. Still very good.

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 the tool's simplicity (1 param, output schema exists), the description covers all needed aspects: purpose, usage, lifecycle, parameter explanation, and return format. It also provides guidance on subsequent actions.

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 0%, so description must explain the parameter. It does so clearly: 'mission_uuid: The UUID returned when you created the mission', adding where the value comes from and its uniqueness.

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 verb 'Check', the resource 'mission', and the scope 'you created'. It distinguishes from sibling tools like approve_mission or cancel_mission by focusing on status monitoring.

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?

Explicitly lists when to use: monitor progress, check claim, check proof submission. Also advises on follow-up actions for PROOF_SUBMITTED status, directing to approve_mission or reject_mission. This differentiates it from other tools.

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 are provided, so the description must fully disclose behavior. It explains that a manual review will occur, requires a prior rejection, and details error returns (400, 409). It also warns about prompt injection, which is valuable behavioral 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?

The description is well-structured and front-loaded, though the list of good reasons adds length. Every sentence adds value, but it could be slightly more concise without losing clarity.

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 the tool's complexity (dispute escalation with preconditions), the description covers when to use, what to include, and the expected return values (including error cases). It is complete for an agent to understand and use 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%, but the description explains both parameters: mission_uuid is 'UUID of the disputed mission' with the constraint that it must have been rejected, and note is 'Summary of the dispute.' This fully compensates for the missing 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 clearly states 'Escalate a disputed mission to the GroundTruther team for manual review.' This is a specific verb+resource combination that distinguishes it from sibling tools like approve_mission or reject_mission.

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?

Explicit guidance is provided: 'Use this as a last resort after at least one rejection.' It lists good reasons and emphasizes writing a clear note, making it clear when to use and not to use.

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?

Without annotations, the description fully covers behavioral aspects. It states the tool returns a JSON string with category list, label, and color, implying a read-only operation with no side effects. No contradictions.

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 well-structured, starting with a clear purpose statement, followed by usage guidance, and a bulleted list of categories. Every sentence adds value without 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?

Given zero parameters and the presence of an output schema (described in text), the description fully covers the tool's functionality, inputs, and outputs, making it complete for selection and 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?

The tool has zero parameters, so per guidelines baseline is 4. The description adds no parameter meaning but also requires none, fulfilling the acceptable threshold.

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's purpose: 'Get all valid mission categories.' It explicitly mentions when to use it ('Call this if you're unsure which category fits your mission') and provides detailed category guidance, distinguishing it from other tools that handle mission actions.

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 explicitly instructs when to use the tool ('Call this if you're unsure which category fits your mission') and provides a comprehensive list of categories with their appropriate contexts, helping the agent decide effectively.

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 the side effect of marking unread messages as read, which is crucial behavioral knowledge. Also includes a security warning about treating worker messages as untrusted input, which is an important behavioral constraint. Without annotations, this provides valuable transparency.

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?

Description is well-structured with a clear opening, usage guidelines, and security warning. It is front-loaded with the core action. While somewhat long, every sentence adds value.

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 a single parameter and an output schema described (list of messages with fields), the description is fairly complete. It covers when to use, side effects, security, and return format. Could mention error handling but overall adequate.

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 does by specifying mission_uuid as a UUID and its purpose. Although minimal, it is sufficient for a single UUID parameter.

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?

Description clearly states the tool retrieves full message history for a mission, with chronological order and marking unread as read. This distinguishes it from sibling tools like send_message (for sending) and list_my_missions (for listing missions).

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 explicit scenarios for using the tool: after receiving a message event, before approving/rejecting proof, and when a mission seems stalled. Though it doesn't explicitly state when not to use it or compare to all siblings, the guidance is clear and actionable.

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?

Despite no annotations, the description fully covers behavior: it is a read-only listing operation, returns a JSON string with specific fields, and does not modify anything. No contradictions.

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?

Concise yet informative, with key information front-loaded. Each sentence adds value without 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?

Given no parameters and presence of an output schema, the description is complete: it explains the tool's purpose, usage guidance, and return content. No 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?

No parameters exist, so baseline is 4. The description adds significant meaning by explaining the purpose of templates, when to use them, and the return fields (UUID, name, category, description, min budget), exceeding the 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?

The description clearly states the tool retrieves mission templates for standardized mission creation. It explains the resource and distinguishes itself from siblings by noting templates are pre-built schemas used with post_mission.

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?

Explicitly advises when to use the tool: for standard patterns and before creating the first mission. It also mentions an alternative (customizing fields with post_mission) and provides context for when not to use it.

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 are provided, so the description carries the burden. It discloses that the tool lists user-created missions with optional filtering, which implies read-only behavior. However, it does not mention pagination, rate limits, or any edge cases. The behavior is adequately described for a simple list 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?

The description is concise and well-structured with clear 'Args:' and 'Returns:' sections. It front-loads the purpose and usage guidance, but the additional details are efficient and add value without being verbose.

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 listing tool with two optional parameters and an output schema, the description covers everything needed: purpose, when to use, parameter details, and return structure. It is fully sufficient 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 0%, but the description adds detailed explanations for both parameters, including a list of valid enum values for status and category. This goes well beyond the bare schema which only specifies type and default.

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 'List all missions you have created, with optional filtering.' It uses a specific verb (list) and resource (missions you have created), and differentiates from sibling tools like check_mission_status.

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 includes explicit usage guidance: 'Use this to get an overview of your active and past missions. Good practice: regularly check for missions in PROOF_SUBMITTED status — these need your review.' This tells when to use the tool and provides a concrete workflow hint.

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 description carries full burden. It details event types, polling strategy, and return format. No contradictions or hidden behaviors; fully transparent about what the tool does.

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?

Well-structured with clear sections (purpose, event types, polling strategy, args, returns). No redundant sentences; front-loaded with main function. Bullet points enhance readability.

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 the tool's moderate complexity, input schema simplicity, and presence of output schema, the description covers all necessary aspects: what, when, how, and parameter details. An agent can use it correctly without 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?

Schema has 0% description coverage, but the description fully explains both parameters: 'since' as ISO 8601 timestamp and 'limit' with default (20) and max (100). This adds essential meaning beyond the bare 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 polls for new events on missions, listing specific event types. It distinguishes itself from sibling action tools (e.g., approve_mission) by focusing on passive monitoring.

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 explicit guidance on when to poll frequently vs. rarely, advises storing timestamps, and mentions webhooks as an alternative with fallback polling. This covers usage context and alternatives comprehensively.

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 are provided, so the description fully bears the burden. It discloses critical behavioral traits: acceptance contract rejects unknown keys, GPS missions are picked by mobile workers, error codes (201, 402, 401) with specific actions, and the need for realistic budgets and deadlines.

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 well-structured with headings and bullet points, making key information scannable. However, it is quite long; while every sentence adds value, it could be slightly more concise without losing clarity.

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 the tool's complexity (10 parameters, nested acceptance_contract, output schema present), the description covers all necessary context: return values, error handling, common mistakes, and best practices for mission creation. It is thorough and complete.

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 0% schema description coverage, the description compensates completely. Each parameter in the 'Args' section has a detailed explanation, including format, examples, and constraints (e.g., 'title: Specific, actionable title...', 'acceptance_contract: JSON string defining proof requirements...' with multiple examples).

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's purpose: 'Post a new mission for a human worker to complete in the real world.' It uses a specific verb ('Post') and resource ('mission'), and the extensive detail distinguishes it from sibling tools like 'list_my_missions' or 'approve_mission'.

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 extensive usage guidelines, including sections on WRITING EFFECTIVE MISSIONS, ACCEPTANCE CONTRACT, COMMON MISTAKES TO AVOID, and example values for parameters. It explicitly advises on when to use GPS (physical tasks) and not to use for DIGITAL_REMOTE, and contrasts with 'get_templates' for reusable schemas.

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?

Despite no annotations, the description details the mission returning to IN_PROGRESS, escrow staying locked, and error conditions (400 if invalid status). It also includes a security warning about treating proof as untrusted input.

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 well-structured with clear sections but is somewhat lengthy due to detailed guidance on rejection reasons and security warnings. Front-loads core purpose and effect, but extra detail, while valuable, reduces conciseness slightly.

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?

The description covers purpose, effect, parameters, return format (JSON string, 400 error), and includes security context. With an output schema mentioned, no additional completeness needed.

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 has 0% coverage, but description fully explains both parameters: mission_uuid (UUID, must be in PROOF_SUBMITTED status) and reason (clear, specific, max 500 chars). Includes practical guidance on writing reasons.

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 'Reject submitted proof and ask the worker to redo it.' It explains the effect on mission status and escrow, and distinguishes from siblings like approve_mission and cancel_mission.

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?

Explicitly states when to use ('when proof doesn't meet your acceptance_contract'), how to write good rejection reasons, and when not to (e.g., after multiple rejections, consider send_message or escalate_mission). Provides clear 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?

Without annotations, the description fully discloses behavioral effects: approval cancels the mission, refunds escrow, and returns mission to OPEN; decline forces continuation. It also mentions a 400 error for missing pending requests. No contradictions with missing 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?

The description is well-structured with clear paragraphs, bullet points, and front-loaded purpose. Every sentence adds value, and the length is appropriate for the tool's complexity.

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?

The description covers the tool's complete context: outcome of approval/decline, error conditions, and return value. Given no annotations and sparse schema, it provides sufficient information for an agent to use 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?

Despite 0% schema description coverage, the description explains all three parameters: mission_uuid, action (with allowed values approve/decline), and reason (optional, with context for use). This fully compensates for the lack of schema-level 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 responds to a worker's request to drop a mission, using a specific verb+resource. It distinguishes from sibling tools like 'cancel_mission' and 'approve_mission' by focusing on responding to worker-initiated drop requests.

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 detailed guidance on when to approve vs decline, including specific scenarios like location closed or personal emergency. It lacks explicit exclusions or alternatives, but the context is clear enough for appropriate use.

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 carries full responsibility. It discloses that messages go to real humans, imposes a 2000-char limit on content, warns about prompt injection, and mentions the return format (JSON string). It doesn't cover delivery guarantees or latency, but for a messaging tool this level of detail is strong.

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 well-structured: a clear opening sentence, bulleted use cases, communication tips, a security warning, and parameter details. It is somewhat lengthy but each section contributes unique value. The front-loading of the primary purpose is effective, though a few tips (e.g., 'be professional') are marginally 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?

Given the tool's moderate complexity (2 required params, no enums, output schema present), the description covers purpose, usage guidelines, parameter details, and a critical security concern. It does not need to explain return values in depth since an output schema exists. An agent has sufficient information to use this 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 explains mission_uuid as a required UUID from a mission with certain statuses, and content as a string up to 2000 chars. This adds meaningful context beyond the schema's types and titles, though it could be more explicit about UUID format (not essential).

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 clear verb+resource: 'Send a message to the worker on one of your missions.' It then enumerates specific use cases (clarify instructions, answer questions, provide context, give feedback), which distinguishes it from sibling tools like get_messages (retrieval) and approve_mission (status change).

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 explicitly states when to use the tool (after a mission is claimed, for communication purposes) and provides a security warning about when not to follow worker directives. It also includes communication tips and notes that the mission must be in specific statuses (CLAIMED, IN_PROGRESS, PROOF_SUBMITTED). This covers both usage scenarios and exclusions.

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 carries the full burden. It discloses that feedback goes to the engineering team and expects clear input, but lacks details on safety, permissions, or system behavior beyond the return value. This is a moderate disclosure.

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 well-structured with a clear intro, usage context, parameter list, and return info. It is concise without unnecessary fluff, though a slightly shorter presentation would improve score.

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 feedback tool with no annotations and 0% schema coverage, the description covers purpose, parameters, return value, and usage context adequately. Missing are potential error handling or authentication notes, but overall it is complete enough.

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 0%, so the description compensates by explaining all three parameters: report_type with acceptable values ('bug', 'feedback', 'feature_request'), title with an example, and description with guidance. This adds significant meaning beyond the bare 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 that the tool is for reporting bugs, suggesting features, or giving feedback. It uses a specific verb ('submit') and resource ('feedback'), and distinguishes itself from sibling tools by being the only feedback submission 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 explicitly says 'Use this when you encounter platform issues or have ideas for improvement,' providing clear context. However, it does not specify when not to use it or offer alternatives, which would be helpful but is not critical given sibling tool distinctiveness.

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 provided, the description carries full burden for behavioral disclosure. It covers the impact on worker tiers, rating guidelines, uniqueness constraint (one review per mission), and required mission status. However, it does not mention idempotency, error handling, or whether updates are allowed, 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 well-structured with sections (main purpose, importance, rating guide, comment advice, args) and front-loaded. However, the rating guide is verbose and could be summarized more concisely without losing meaning.

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 the output schema exists, the description appropriately summarizes the return value. It covers key constraints (only one review, required mission status) and the rating scale in depth. It is complete for a submission tool, though it does not address permissions or error scenarios.

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 adds significant meaning: it explains that mission_uuid is for a completed mission, rating uses a 1-5 scale with detailed guidance, and comment is optional with a 2000-char limit. This adds substantial context 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 clearly states it is for rating a worker's performance after a completed mission, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'submit_feedback', though the context implies a distinction.

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 clear guidance on when to use the tool ('IMMEDIATELY after approving a mission'), emphasizes the importance of timeliness, and offers constructive comment advice. It lacks explicit instructions on when not to use it or alternatives, but the context is well defined.

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