Molt2Meet

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

Beyond annotations, it discloses the state transition ('Transitions directly to Closed'), the absence of escrow/fund release, and the settlement modalities (cash, pin, QR, Tikkie). This is significant behavioral context not present in annotations and directly relevant to the agent's decision-making.

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 tightly written sentences, each carrying essential information. The opening 'DIRECT SETTLEMENT FLOW ONLY' immediately signals scope, and every sentence adds a distinct constraint or behavioral detail 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 the tool's simplicity and the presence of a full input schema, the description covers prerequisites (task type and status), behavior (transition to Closed), exclusions (no escrow, no fund release), and a sibling alternative. No obvious gap for an agent to invoke it 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 input schema already provides 100% coverage for all parameters. The description adds meaningful context for the taskId parameter by requiring it to reference a DirectSettlement task in Completed status, which goes beyond the schema's generic 'Task ID to acknowledge'.

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 ('confirms') and resource (direct settlement task), and details the action: confirming operator completion and on-site payment. It clearly distinguishes this tool from siblings by naming the direct settlement flow and contrasting with approve_task_review.

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 says 'DIRECT SETTLEMENT FLOW ONLY', specifies the task must be a DirectSettlement task in Completed status, and gives an explicit alternative: 'For escrow tasks use approve_task_review instead.' This leaves no ambiguity about when to use the tool.

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 are minimal (all false), so the description carries full behavioral burden. It discloses the side effect of creating a notification channel, details webhook authentication behavior (authType values, default header, query param appending), and provides concrete examples. No contradiction with 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 front-loaded with the core purpose, then efficiently covers usage and auth details with examples. Every sentence adds practical information, no fluff or redundancy, and it's appropriately sized for a tool with this level of configuration 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?

For a tool that configures webhook auth, it covers prerequisites, method selection, detailed auth instructions with examples, and downstream alternatives. The absence of an output schema is acceptable since a successful add likely returns a simple confirmation; the description fully equips an agent to invoke 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?

Although schema coverage is 100%, the description adds significant meaning beyond the schema: it explains how configJson is structured with real examples, clarifies how methodType relates to endpoint, and details each authType's wire-level behavior (e.g., 'basic' sends user:pass as Authorization: Basic header). This greatly improves schema-only understanding.

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 'Add a notification channel for task status events' with specific examples ('operator accepts, uploads proof, etc.'). It distinguishes itself from sibling tools by contrasting account-wide notifications with per-task events handled by 'dispatch_physical_task with webhookUrl'.

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 prerequisites ('Requires: API key from register_agent'), provides guidance on choosing methodType ('webhook' with URL, 'email' with address), and names alternatives ('Next: dispatch_physical_task... or use this for account-wide notifications'). This gives clear when-to-use and when-not-to-use context.

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 readOnlyHint=false and destructiveHint=false, so safety profile is covered. The description adds meaningful behavioral context beyond annotations: it explains that service interest 'feeds into operator recruitment priority' and that no execution occurs, plus notes the API key requirement and verification via list_service_interests. Minor gap: no mention of whether adding interest is idempotent or can be removed, but annotations partly cover side effects.

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 longer than average but every sentence earns its place: purpose, contrast, usage, mechanism, analogy, use cases, requirements, and next steps. It is well-structured and front-loaded with the core distinction, though slightly verbose with the em-dash style and multiple clauses. No fluff.

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 7 parameters, no output schema, and relatively generic annotations, the description provides rich context: what it does, how it works, when to use it, prerequisites, optional category linkage, and follow-up actions. It fully equips the agent to decide when and how to invoke the tool, and explains the system-level effect (recruitment priority).

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 purpose of region (no location of a task but a region-level signal), referencing serviceCategoryId from list_service_categories, and noting apiKey comes from register_agent. This goes beyond the schema's field-level descriptions, making parameter semantics clearer.

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, specific verb 'Signal' and resource 'a category of physical-world tasks in a region,' immediately distinguishing it from dispatching a concrete task. It explicitly contrasts with dispatch_physical_task and positions itself as a forecast/intent signal, making the purpose unmistakable even among many 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?

The description states exactly when to use it: 'when you don't yet have a specific job but you know you will need this kind of task in this region.' It also names the alternative (dispatch_physical_task) and a similar tool (join_country_waitlist), and lists concrete use cases like long-term planning and pre-commitment, providing clear decision guidance.

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 indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that authentication is required and that it records feedback, which is useful context. However, it does not disclose other behavioral traits like idempotency (already false in annotations) or potential side effects, so it provides only modest value 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?

The description is three short sentences, front-loaded with the primary purpose. Every sentence adds value: purpose, scope, and a key differentiation from sibling tools. No wasted words.

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 (7 parameters) and the excellent schema coverage, the description provides the essential context: what it does, when it applies, and how it differs from similar actions. It mentions authentication and the feedback nature. It lacks detail on the response format, but no output schema is present and for a write operation, this is acceptable. Overall, it is complete for an agent to invoke it 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 input schema has 100% coverage with descriptions for all parameters. The description redundantly mentions 'rating' and 'work quality' but does not add new meaning beyond the schema. The baseline is 3 because the schema does the heavy lifting.

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 action ('Add a review/rating') and the target resource ('for a completed task'). It explicitly distinguishes itself from approve/reject, which are sibling tools, by noting it 'records feedback' rather than approving or rejecting.

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 specifies the context of use ('for a completed task') and provides a clear differentiation from approve/reject by stating it is separate. It does not explicitly list alternative tools or edge cases where it should not be used, but the distinction is sufficient for an agent to select it appropriately.

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?

While annotations provide idempotentHint and readOnlyHint, the description adds critical behavioral details: marks task Completed, triggers immediate operator payout, no review window, and error response for escrow tasks. This exceeds annotation coverage without any contradiction.

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 dense yet well-structured, using a dash and line breaks to separate key sections. Every sentence provides necessary context with no fluff, balancing completeness and brevity.

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 output schema and moderate tool complexity, the description covers preconditions, mechanism, status requirements, alternative tools, and next steps (monitor settled/closed). It is fully self-contained for an agent to 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 covers both parameters with descriptions, but the description enriches their semantics by stating the API key must come from register_agent and the taskId must be in ProofUploaded or UnderReview status. This adds meaningful constraint information 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 that this tool approves a completed task in the simple flow, distinguishing it from approve_task_review used for escrow flow. It uses a specific verb 'approve' plus resource 'physical task completion' and explicitly calls out 'SIMPLE FLOW 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 explicit preconditions (publishImmediately=true, auto-funded), states when not to use (escrow flow), names the alternative tool (approve_task_review), and describes the error behavior that guides the user to the correct tool. It also specifies required task statuses.

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 idempotentHint=true and destructiveHint=false, so the safety profile is known. The description adds useful context: 'Requires authentication' and the conditional 'when you agree.' No contradictions with 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 two sentences long and front-loaded with the core purpose. Every sentence contributes value—stating the action, when to use it, and a prerequisite. No wasted words.

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 tool is simple, with a complete schema and no output schema required. The description covers purpose, usage, and authentication. It could mention post-approval effects, but this is not necessary given the straightforward nature of the action.

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?

All three parameters have clear descriptions in the schema (100% coverage). The tool description itself adds no additional parameter-level meaning beyond what the schema already provides, so the baseline score 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 description clearly states the action: 'Approve a reschedule request.' It uses a specific verb and resource, and the phrase 'when an operator has requested a reschedule and you agree' distinguishes it from sibling tools like reject_reschedule and request_reschedule.

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 explicit condition for use: 'Use this when an operator has requested a reschedule and you agree.' However, it does not explicitly mention alternatives or when not to use it, such as referencing reject_reschedule for disagreement.

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 signal non-read-only and idempotent behavior. The description adds valuable context about the payout side effect ('Funds move from locked to earned'), prerequisites, and the 400 error on direct tasks, going beyond what annotations provide.

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 three sentences, front-loaded with the most critical distinction ('ESCROW FLOW ONLY'), then the alternative, then the action and conditions. Every sentence provides essential information with no fluff.

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 state-changing financial tool with no output schema, the description covers when to use, what it does, side effects, prerequisites, authentication, and error behavior for misuse. It is comprehensive enough for an agent to correctly select and invoke the 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?

Schema coverage is 100% for 'apiKey' and 'taskId', but the description adds meaning to 'taskId' by specifying it must refer to a task in UnderReview status with settlementMode='escrow'. This is additional eligibility context beyond the schema's simple 'Task ID to approve'.

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 a specific action: 'Approve a completed task after reviewing the proof' and its result: 'Triggers payout to the operator.' It also explicitly distinguishes from sibling tools by stating 'ESCROW FLOW ONLY' and naming the direct-settlement alternative.

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 usage guidance is provided: it states this is for escrow-flow tasks only and directs users to use 'acknowledge_direct_settlement_task' for direct-settlement tasks, including the error behavior otherwise. It also specifies the required task status and settlementMode, giving clear conditions for 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?

Annotations already indicate destructiveHint=true and idempotentHint=true, and the description adds valuable context by stating the task must be undispatched/unpaid and that an API key from register_agent is required. This goes beyond the annotations without contradicting them.

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 two sentences, front-loaded with the action and immediately followed by key constraints. Every word earns its place, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation tool with annotations covering destructive/idempotent behavior, the description includes preconditions and auth requirements. It does not detail post-cancellation effects or return values, but given the straightforward nature and schema coverage, it is largely 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?

Schema descriptions cover 100% of parameters, providing a baseline of 3. The description adds nuance by specifying the apiKey should come from register_agent, which is not explicitly in the schema ('Your Molt2Meet API key'). This small addition justifies a 4.

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 'Cancel' and the resource 'dispatched physical-world task', with a specific scope ('Only tasks not yet completed or paid can be cancelled'). This distinguishes it from sibling tools like cancel_task_with_settlement.

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 a clear precondition ('only tasks not yet completed or paid') and a prerequisite ('Requires: API key from register_agent'), giving context for when to use the tool. However, it does not explicitly mention alternatives for other cancellation scenarios (e.g., settlement-related), so it falls short of a 5.

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?

The description discloses important behavioral details beyond the annotations, such as operator compensation depending on task status, refunds to agents, and authentication requirements. These add significant context that annotations do not cover.

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 three sentences, front-loaded with the main action, and every sentence provides necessary information. No wasted words.

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, the description covers the essential behaviors: cancellation, settlement, compensation, refund, and auth. It lacks output schema details but provides sufficient context for an agent to understand the tool's effect.

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 schema fully covers all three parameters (apiKey, taskId, cancellationReasonCodeRef), so the baseline is 3. The description does not add additional meaning about the parameters themselves, only about the overall behavior.

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 cancels a task with financial settlement, using a specific verb and resource. It distinguishes from siblings like cancel_physical_task by highlighting the financial settlement aspect.

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 tasks requiring financial settlement, but it does not explicitly mention alternatives or when not to use this tool. The context is clear but lacks exclusionary guidance.

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?

Beyond the annotations (readOnly=false, not idempotent), the description discloses critical behaviors: returns a checkout URL, wallet is automatically credited after payment, and the currency resolution logic. It also notes 'Requires authentication,' which is useful 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 concise and well-structured, leading with the core purpose, then describing the return value and credit behavior, and finishing with a clear numbered list for currency resolution. No redundant or extraneous 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?

Despite lacking an output schema, the description covers the full operational context: what the tool does, what it returns (checkout URL), post-payment behavior, and how it relates to fund_task. This is sufficient for an agent to invoke it correctly without additional lookups.

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 input schema already documents all 6 parameters at 100% coverage, so baseline is 3. The description adds a richer explanation of the currency default hierarchy (explicit currency, single existing wallet, most-recent task currency) that goes beyond the schema's 'smart default' note.

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 primary function: 'Create a hosted checkout session (e.g. Stripe) to deposit funds into your wallet.' It also distinguishes itself from sibling tools by explicitly referencing fund_task and when to use this tool instead.

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 usage guidance: 'Use this before fund_task if your wallet balance is insufficient.' It also details the smart default currency resolution order, helping agents decide when and how to invoke the tool correctly.

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?

Description discloses that the tool syncs with the payment provider and automatically funds the task if sufficient balance exists, adding behavioral detail beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false). It also notes authentication requirement, though that's implied by the apiKey parameter.

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 serving a purpose: warning, function, usage context, and authentication/sync behavior. No filler or 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?

The description covers purpose, scope, usage timing, and side effects comprehensively for a moderate-complexity tool. However, with no output schema, it fails to describe the return value or error conditions (e.g., what happens when no payment is received), which is a minor 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?

Input schema already fully describes both parameters (apiKey and taskId) with 100% coverage. The description does not add additional parameter-specific semantics beyond the schema, so baseline score 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 clearly states the tool checks for PSP payment and funds the task, explicitly scoping to escrow flow and excluding direct-settlement tasks. This specific verb-resource pairing distinguishes it from sibling tools like fund_task and acknowledge_direct_settlement_task.

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 guidance: only for quoted escrow tasks after payment via checkout URL or bank transfer, and explicitly warns not to call on settlementMode='direct' tasks. This gives clear context for tool selection without naming alternatives but by exclusion.

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 only state readOnlyHint=false, destructiveHint=false, etc. The description adds crucial behavioral details beyond annotations: the plaintext key is returned only once, only a hash is stored, and multiple keys can be active for rotation. This is exactly the kind of context an agent needs.

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 compact and well-structured: first the action, then the security warning, then usage context, then rotation workflow. Every sentence adds value with no redundancy or filler.

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?

Despite no output schema, the description explicitly states what is returned (the plaintext key) and its one-time nature. It covers prerequisites, follow-up actions, and rotation behavior, making it complete for an agent to invoke correctly and handle the result safely.

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 for both parameters, but the description adds extra semantics: keyName is used to identify purpose with examples, and the apiKey must come from register_agent. This enriches the schema and helps the agent understand the parameters' roles in the overall key lifecycle.

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: 'Generate a new API key for your agent.' It specifies the resource (API key) and the action (generate), and differentiates from sibling tools like revoke_api_key by describing the key creation process including the returned plaintext key.

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 explicit when-to-use guidance and workflow context: 'Requires: an existing API key from register_agent. Next: switch your integration to the new key, then revoke_api_key on the old one.' It also mentions rotation use case, making it clear when to use this tool vs 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?

Annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds far more: asynchronous execution, auto-publish fallback with Draft save, scheduling mode auto-detection, local-timezone semantics, idempotency via requestId, webhook authentication requirements, and proof validation behavior. No contradictions with annotations; it greatly expands on their meaning.

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 long, but the tool is highly complex (38 params, multiple modes, async behavior, timezone rules). It is well-structured: opening with a one-line purpose, then grouping related concepts (coverage, async, auto-publish, scheduling, timezone, idempotency, webhooks, proof). Some content duplicates schema descriptions (e.g., proofRequirementsJson keys), so not every sentence earns its place, but the overall organization makes the length acceptable.

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 complexity and lack of an output schema, the description covers all critical gaps: response shape (taskId, next_actions, autoPublishDeferred), operational flow, prerequisites, error-prone timezone handling, idempotent retry behavior, and follow-up tool references. It tells the agent what to expect and what to do next, making the tool actionable in nearly all 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?

Although schema coverage is 100%, the description adds cross-cutting parameter semantics not obvious from schema: the yyyyMMddHHmmss local-time format, the auto-detection logic for executionMode, the exact proofRequirementsJson keys with an example, and the meaning of publishImmediately's fallback. It highlights which structured fields to use and how they interact (e.g., deadlineAt vs completeBy vs timeWindowStart/End). The description significantly raises the effective understanding of parameters 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 opens by identifying this as the 'Primary tool' and clearly states the verb's action: 'Dispatch a human operator to perform a physical-world task at a specific location and return verifiable proof (photos, GPS, timestamps, report).' This explicitly distinguishes it from sibling tools like get_physical_task_details or approve_physical_task_completion. The purpose is unmistakable.

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 explicit usage guidance: it names prerequisite calls (list_service_categories, list_countries), tells when NOT to use the tool (non-Live countries → use join_country_waitlist), and gives clear next steps (get_physical_task_details, approve_physical_task_completion). It even explains the alternative funding path via request_task_quote → fund_task → publish_task when auto-publish is deferred.

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?

The description discloses the key state transition (Completed → Disputed) and adds important context about the platform's limitations ('no financial leverage'). While annotations provide only false flags with no safety signals, the description conveys the core behavioral outcome and constraints without contradicting 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?

The description is compact and front-loaded: it states the scope first ('DIRECT SETTLEMENT FLOW ONLY'), then the action, transition, and caveat, followed by an alternative. Every sentence contributes meaningful information with no 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 tool with three simple parameters and no output schema, the description adequately covers purpose, usage context, state transition, and constraints. It lacks explicit details about error conditions or response format, but given the tool's simplicity and the presence of full schema descriptions, it is sufficiently 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?

Schema coverage is 100%, so the baseline is 3. The description adds slight meaning by indicating that the 'reason' parameter relates to 'the work or the on-site payment,' but this is a minor embellishment. It does not significantly improve understanding beyond the schema descriptions already present.

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 specific action: 'Agent raises a dispute about the work or the on-site payment.' It also defines the resource and transition ('Task transitions from Completed → Disputed'), and explicitly distinguishes itself from the escrow dispute flow, making it distinct from sibling tools like open_task_dispute.

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 opening 'DIRECT SETTLEMENT FLOW ONLY' immediately indicates the intended context, and the final sentence provides an explicit alternative: 'For escrow disputes use the standard dispute flow.' This clearly tells the agent when to use this tool and when not 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?

Despite idempotentHint=true annotation, the description adds substantial behavioral context beyond annotations: detailed money flow for PSP (two-step wallet credit then lock), cancellation behavior (money stays in wallet, no auto-refund), idempotent re-invocation behavior (returns same checkout URL), lock duration until approval, and 400 error on direct-settlement tasks. No annotation 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 long but front-loaded with the most critical scope restriction and precondition. Each paragraph covers a distinct aspect (methods, money flow, idempotency, next steps, response fields) without redundancy. Slightly verbose, but the complexity (money handling, PSP nuances) justifies the length.

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 compensates by explaining response fields ('nextActions array', 'chargedAmount' vs legacy 'grossAmount', fundingTrace in check_task_funding), error conditions, preconditions, idempotency, cancellation semantics, and next-step flow. It is comprehensive enough for a money-moving 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?

Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics to fundingMethod ('wallet' instant vs 'psp' hosted checkout URL, requires principal completion, auto-funds), plus fallback behavior for insufficient balance. It does not repeat schema details for locale/URLs but enriches the critical fundingMethod 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?

The description states a clear verb-resource-scope: 'Fund a quoted task using wallet balance or PSP payment — second step of the escrow funding flow.' It immediately distinguishes from direct-settlement tasks ('ESCROW FLOW ONLY... Calling this on a direct-settlement task returns 400') and positions itself relative to siblings like request_task_quote and publish_task.

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/when-not guidance: precondition 'task must be in Quoted status AND settlementMode='escrow'', direct exclusion of direct-settlement tasks, fallback advice ('switch to 'psp', or call checkout_wallet_deposit / get_bank_transfer_details'), and clear next steps ('Next: publish_task after wallet funding... call check_task_funding to poll').

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?

The description adds valuable behavioral context beyond the annotations: it explains the currency resolution algorithm, the fact that the wallet is credited automatically after payment, and the error condition when no currency is available. It also explicitly states 'No stale USD default', which is a useful non-obvious behavior. The annotations only indicate basic hints, so the description carries the transparency burden well.

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 with the core purpose. It uses five sentences, each conveying necessary information, including the checkout URL, automatic crediting, currency resolution, and the no-stale-default note. There is minimal waste, though the final 'Requires authentication' is already implied by the apiKey parameter, slightly lengthening it.

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 tool has no output schema, so the description's mention of returning a checkout URL is essential and adequately covers the return value. It also covers the payment lifecycle and currency edge cases. It does not discuss idempotency or URL expiration, but given the simplicity of the tool and the annotations provided, it is sufficiently 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?

The input schema already provides 100% coverage with descriptions for all parameters, which sets a baseline of 3. The description goes further by explaining the smart default resolution for the currency parameter in exact order, and the error behavior if no currency is determined. This adds meaningful guidance beyond the schema's simple 'Omit for smart default' note.

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 with a specific verb ('Add funds') and resource ('your wallet'), and specifies the key output (checkout URL). It distinguishes itself from sibling tools like fund_task by focusing on wallet funding rather than task funding, and from checkout_wallet_deposit by describing the automatic crediting after payment.

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 context on when to use the tool: when you need to add funds to a wallet via a payment provider. It also details the currency default resolution order, which helps users decide when to omit the currency parameter. However, it does not explicitly mention alternative tools or exclusions, so it stops short of a 5.

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, covering the safety profile. The description adds the auth need that the API key must come from register_agent, which is valuable beyond the schema (which only says 'Your Molt2Meet API key'). This is a meaningful additional 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?

Two short sentences with front-loaded purpose ('Retrieve your profile and status') and a concise requirement. Every word earns its place; no filler or repetition of schema details.

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 (one parameter), rich annotations, and no output schema, the description sufficiently conveys the purpose and auth requirement. It does not explain return values in detail, but for a basic read operation this is acceptable and not a major 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 apiKey described as 'Molt2Meet API key (starts with m2m_)'. The description adds that the key is obtained from register_agent, which provides provenance beyond the schema. This extra semantic detail justifies a score above the baseline of 3.

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 'Retrieve your profile and status' uses a specific verb and resource, clearly distinguishing this from sibling tools like update_agent_profile and get_wallet_balance. It directly states what the tool does without 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?

The description implies usage by stating its purpose but does not explicitly state when to use it versus alternatives or provide exclusions. It only mentions a prerequisite ('Requires: API key from register_agent'), which is context but not full usage guidance.

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, and non-destructive behavior. The description adds valuable context beyond those: each agent has a unique IBAN, the wallet is credited automatically upon transfer receipt, SEPA transfers take 1-3 business days, and there is a specific currency resolution fallback. It does not explain the exact response format, but the added behavioral details are substantial.

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 moderately long but every sentence contributes: purpose, unique IBAN, crediting process, timing, alternative, currency logic, and auth requirement. It is front-loaded with the main purpose and structured logically, though it could be slightly tightened.

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 moderate complexity and the presence of annotations and full schema coverage, the description is fairly complete. It explains the workflow, timing, currency resolution, and authentication. It does not detail the response contents, but the tool name and purpose make this reasonably inferable. The differentiation from sibling tools further supports completeness.

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 schema already covers all three parameters with descriptions (100% coverage), so a baseline of 3 applies. The description adds meaningful semantic value, particularly for the `currency` parameter, by detailing the smart default fallback chain (explicit currency, then single wallet, then most-recent task). This goes beyond the schema's 'smart default' mention.

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 function: 'Get IBAN bank transfer details for funding your wallet.' It uses a specific verb ('Get') and resource ('bank transfer details') and distinguishes itself from siblings by noting it is 'an alternative to PSP checkout for wallet funding.' This makes the purpose unambiguous and differentiated.

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 usage context: it is for wallet funding via bank transfer, mentions the process and timing, and explicitly names the alternative (`PSP checkout`). However, it does not explicitly state when not to use it (e.g., if instant funding is needed), so it falls just short of a 5.

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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description reveals critical behavioral traits: decision requests are BLOCKING, the operator is waiting, the response includes a pre-filled nextActions array, and authentication is required. This adds meaningful context about side effects and workflow that annotations alone do not capture.

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 information-dense, beginning with a purpose sentence, followed by 'Mechanism:', examples, triggers, response details, and next steps. Each sentence serves a distinct purpose, and the format makes it easy to scan, especially for a tool with a blocking mechanism and workflow implications.

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?

Despite no output schema, the description explains the key return elements (nextActions array with resolve_decision_request actions, pre-filled decisionId and questionCode). It also covers triggers, examples, blocking behavior, and the follow-up action, making the tool's role in the overall workflow clear. This is highly complete for a simple two-parameter read 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 input schema covers 100% of parameter descriptions (apiKey and taskId). The description does not add additional parameter-level semantics beyond schema, though it mentions 'Requires authentication' which loosely connects to apiKey. The schema already provides the necessary detail, so the description contributes minimal added value here.

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 begins with a clear, specific statement: 'Get pending decision requests for a task.' It distinguishes itself from related sibling tools by focusing on 'decision requests' and mentioning the companion 'resolve_decision_request' action. The detailed explanation of what decision requests are (questions from platform/operator) further clarifies the tool's exact purpose.

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 explicit triggers for when to use the tool ('task.decision_requested webhook event' or seeing the count in get_pending_actions.decisionRequests.count) and clearly states the next step ('Next: resolve_decision_request'). It does not explicitly state when *not* to use it or name a competing alternative tool, but the context is strong enough for an agent to determine appropriate 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?

Annotations already indicate readOnlyHint and idempotentHint, but the description adds valuable context: document types are configurable via an app setting, typical document types are listed, and the exact fields returned are specified. It also states that no authentication is required.

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 three sentences, front-loaded with the core purpose, followed by configuration details and output/usage notes. Every sentence adds useful information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fully covers return values (fields like version, effective date, markdown content). It also explains the registration context, configurable nature, and lack of auth, making it self-sufficient for an agent to decide when and how to use 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?

The input schema has zero parameters, so there is nothing to explain. The description's mention of the configurable setting is contextual rather than parameter-related, aligning with the baseline of 4 for a no-parameter 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?

The description clearly states the tool's function: retrieving all active legal documents an agent must accept on registration. The verb 'Get' and resource 'legal documents' are specific, and the reference to register_agent distinguishes it from sibling tools.

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 to call this before register_agent, providing a concrete usage sequence and context. While it does not list alternatives, no other tool handles legal documents, so the 'when' guidance is sufficient.

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, so the agent knows it is a safe read. The description adds behavioral context by listing the categories of returned data and emphasizing the 'single call' nature, beyond what annotations offer. It does not disclose edge cases or rate limits but adds meaningful 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 three sentences long, with each serving a clear purpose: what it does, what it returns, and when to use it. There is no wasted wording or redundancy, making it highly concise and well-structured.

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 read-only tool with one parameter, the description is quite complete. It covers purpose, return categories, and usage guidance. It lacks an output schema, but the description compensates by listing the key response components. It could be more detailed about the semantics of 'wallet summary' and 'webhook health', but this is sufficient for the tool's complexity.

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% because the only parameter (apiKey) has a description in the schema. The description merely repeats 'Requires: API key' without adding new meaning. Baseline of 3 is appropriate because the schema already handles the parameter 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?

The description clearly states you can 'Check if you have any pending actions in a single call' and enumerates the exact types of data returned (tasks, decision requests, support tickets, wallet summary, webhook health). This distinguishes it from the many sibling tools by presenting it as an aggregate overview rather than a single-purpose endpoint.

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 explicitly says 'Use this to efficiently poll for work instead of calling multiple endpoints', which gives a clear when-to-use directive and implies an alternative (calling multiple separate endpoints). However, it does not name specific sibling tools as alternatives, so it falls slightly short of the highest standard.

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 mark it as read-only, idempotent, and non-destructive. The description adds behavioral context by explaining the SLA countdowns are for 'timezone-safe polling' and that includeEvents inlines event history to save a round-trip. It also discloses the API key requirement. No contradictions with 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 compact yet information-dense, covering purpose, response contents, optional flags, prerequisites, and next steps in five sentences. Each sentence adds unique value with no redundant phrasing or filler.

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?

Even without an output schema, the description enumerates the main response components (operator status, proof, timestamps, decision requests, SLA countdowns) and explains optional behaviors. It also provides the follow-up workflow, making it fully self-contained for an agent to decide when and how to invoke the 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 input schema already describes all four parameters, so the baseline is solid. The description enhances includeEvents and includePolicyText by explaining their purpose and trade-off (avoiding extra calls), and clarifies the apiKey source. This goes beyond mere 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 it retrieves full details of a physical-world task and enumerates specific content areas (operator status, proof, timestamps, pending decision requests). This distinguishes it from sibling getters like get_task_events and get_task_proofs by the comprehensive detail set.

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: includeEvents=true saves a round-trip to get_task_events, and includePolicyText embeds policy text instead of fetching it from other sources. It also notes the prerequisite of an API key and suggests next actions (approve_physical_task_completion or cancel_physical_task) based on task status. While it doesn't enumerate all cases for not using this tool, the alternatives and follow-ups are clear.

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 and destructiveHint=false, covering the safety profile. The description adds valuable context by specifying the return fields (request IDs, subjects, statuses, timestamps) and noting optional filtering, which goes beyond what annotations provide.

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 three short sentences, front-loaded with the action 'List.' Each sentence adds essential information without fluff, and the structure is easy to scan.

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 read-only list tool, the description covers purpose, filters, and return fields. Combined with strong annotations and full schema coverage, it is complete enough for an agent to invoke correctly, though it omits potential extras like pagination or sorting.

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 schema provides 100% description coverage for all three parameters, including enums and defaults. The description merely restates that filtering by type/status is optional, adding no new semantics 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 uses a specific verb 'List' and clearly identifies the resource as 'support requests, complaints, and recommendations.' It also mentions optional filters and return fields, which distinguishes it from sibling tools like reply_to_support_request and submit_support_request.

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 clearly implies when to use this tool: when you need to list support requests. However, it does not explicitly name alternatives or exclusions, unlike some high-scoring examples. The context is clear but lacks explicit 'when-not-to-use' guidance.

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, and destructiveHint=false. The description adds substantial behavioral detail beyond this: it mentions authentication requirements, describes event contents including actor info and location objects, and reveals the anti-fraud use case (ProofValidationService). This gives the agent deep insight into operational behavior.

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 dense paragraph of 4 sentences with no filler. It front-loads the purpose ('Poll for task status changes'), then logically details return values, event structure, and usage. Every sentence contributes 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?

The description covers purpose, authentication, event structure, and parameter usage, which is sufficient for a read-only polling tool. However, it does not specify behavior when 'after' is omitted (default null), nor does it mention response format details like pagination or empty-result behavior. Given the lack of an output schema, a bit more explicit completeness would be ideal.

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 parameters are already documented. The description adds practical guidance for the 'after' parameter ('after=lastEventId for incremental polling; pass after=0 for all events'), clarifying its semantic role beyond the schema's basic description. It does not add much for apiKey or taskId, but the schema already covers them.

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 with a specific verb+resource: 'Poll for task status changes.' It further clarifies that it returns status history entries after a sequence number, distinguishing it from likely sibling tools like get_task_history that might return full history.

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 usage context: 'Use after=lastEventId for incremental polling; pass after=0 for all events.' It implies the tool is for polling new events but does not explicitly contrast it with alternatives or state 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, giving the safety profile. The description adds beyond this by noting 'Requires authentication' and specifying that it shows all transitions with timestamps and reasons, providing useful behavioral context not present in 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?

The description is three sentences, each adding distinct value: what it does, what it shows, and why it's useful plus an auth requirement. It is front-loaded with the core purpose and contains no filler, earning a perfect 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?

Though no output schema exists, the description conveys the return content well (status transitions, timestamps, reasons) and mentions authentication. While it doesn't explicitly cover ordering or pagination, for a simple read-only tool this is largely complete; a 5 would require more details on edge cases or return structure.

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?

Both parameters (apiKey, taskId) have full descriptions in the schema, so even though the description adds no parameter-specific details, the 100% schema coverage gives a baseline of 3. The description does not enhance or clarify the parameter semantics further.

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 retrieves the full status history of a task, naming the resource and specific verb. It is specific about what it shows (status transitions with timestamps and reasons), but it does not explicitly differentiate itself from the sibling tool get_task_events, so it stops short of a 5.

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 'Useful for understanding the task lifecycle progression' provides an implied use case, but there is no explicit guidance on when to use this tool versus alternatives like get_task_events, nor any exclusions. This is minimal viable guidance.

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, and destructiveHint=false, and the description adds valuable behavioral context: thumbnail size estimates (~5-15KB each), REST endpoint behavior, nextActions context-awareness, and an explicit 'Requires authentication' note. No contradiction with 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 longer than average but well-structured with a numbered list. Every sentence serves a purpose—explaining levels, endpoints, and nextActions—so the length is justified. Not maximally concise, but efficient for the 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?

Given there is no output schema, the description covers return contents (metadata, GPS, validation), response size implications, alternative endpoints, authentication, and nextActions behavior. It does not detail the exact JSON structure, but for a read-only get operation with this level of guidance, it is sufficiently complete for an agent to 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?

With 100% schema coverage, the baseline is 3, but the description enriches parameter understanding by explaining the trade-off of includeThumbnails (lightweight vs inline base64) and suggesting REST endpoints as an alternative to avoid pulling all thumbnails. This goes beyond the schema's field 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 opens with a precise verb+resource statement: 'Get all proof items submitted by the operator for a task.' It clearly distinguishes this from sibling tools by focusing on proof items and enumerating return types (metadata, GPS stamps, validation results), making it unique among get_task_* tools.

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 provides clear instructions on how to choose between default lightweight output and includeThumbnails=true, plus alternative REST endpoints for single thumbnails and raw content. It implies usage context ('when you need proofs') but doesn't explicitly name alternatives or exclusions, so a point is deducted.

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 and idempotentHint=true, and the description adds the auth requirement and the null-means-global behavior. This goes beyond annotations by explaining the return context, though it doesn't address error scenarios.

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 two sentences, both essential, and front-loads the purpose. The null caveat is included efficiently 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?

For a simple read-only tool with one parameter and no output schema, the description explains the return values (position and country) and the required input. It lacks an exact return format but is adequate for the simplicity of the 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 schema fully documents the apiKey parameter with a clear description, but the tool description adds that the key must come from register_agent, which provides useful sourcing context 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 the user's waitlist position and country, using the specific verb 'check' and the resource 'waitlist'. It distinguishes itself from siblings like join_country_waitlist by focusing on status retrieval rather than joining.

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 names a clear prerequisite (API key from register_agent), telling the agent when it can use the tool. It does not explicitly exclude alternatives or list when-not-to-use, but the context is specific enough for a read-only status check.

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?

The description provides detailed behavior not captured in annotations: the exact currency resolution rules (explicit > single wallet > most recent task), the absence of a stale USD default, the meaning of each of the four balance numbers, and the per-task locks array. Annotations already declare read-only and idempotent, and the description does not contradict; it adds crucial context about the response semantics.

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 organized with clear sections: purpose, currency resolution, field definitions, locks array, usage context, and alternative. Despite being longer than average, every sentence adds essential information about balance semantics that the agent needs. The priority ordering is front-loaded and each sentence 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?

Given there is no output schema, the description fully explains the structure and meaning of the response, including the locks array field names. It also covers when to use the tool, authentication, and the relationship between balance components. This is complete 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%, so baseline is 3. The description elaborates on the currency parameter's default resolution logic and explicitly says omitting currency uses smart default, adding meaning beyond the schema. The apiKey parameter is sufficiently described in the schema, so no further description is needed.

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 'Get your wallet balance for a specific currency,' clearly stating the verb and resource. It distinguishes itself from the sibling tool list_wallets by explicitly directing 'For all currencies at once, use list_wallets.' The scope is precise and unambiguous.

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 explicitly states 'Use this before fund_task to verify you have sufficient available funds,' giving a concrete when-to-use scenario. It also names the alternative for all currencies (list_wallets), which directly addresses tool selection.

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 and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: it explains the return includes 'running balance', describes the currency resolution fallback chain, and explicitly states 'Requires authentication.' These details go beyond the annotations and help the agent understand side effects and prerequisites.

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 three sentences long and every sentence earns its place. It front-loads the core purpose, then adds filtering, currency resolution, and authentication. No redundant or vague language.

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 read-only wallet transaction history tool with good annotations, the description covers purpose, filtering, currency behavior, and authentication. It does not mention pagination or rate limits, but these are not critical for this simple list operation. The level of detail is adequate for an agent to invoke it 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 descriptions for all parameters, so the baseline is 3. The description adds extra semantics, especially for the currency parameter: it explains the smart default resolution rules and explicitly states 'No stale USD default.' This clarifies behavior beyond the schema's simple 'Currency code' description. The taskId parameter is also reinforced by 'Optionally filter by task ID.'

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 function: 'Get your wallet transaction history. Shows all ledger entries with running balance.' It specifies the resource (wallet transactions), the action (get), and the scope (all ledger entries with running balance). It also mentions optional filtering by task ID, which distinguishes it from sibling tools like get_wallet_balance or get_bank_transfer_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 provides clear context on when to use the tool, such as filtering by task ID and the smart default currency resolution logic. However, it does not explicitly name alternative tools or state when not to use this tool versus a sibling like get_wallet_balance. The guidance is present but lacks explicit 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?

Goes beyond annotations by explaining what idempotence means here: calling again with a different country updates preference, and only one country per agent is allowed. Also discloses the notification behavior when the country becomes Live and that signup influences launch prioritization. No contradiction with 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 sequencing, but the sentence about demand signal and recruitment prioritization, while contextually interesting, is not strictly necessary for tool invocation. Still, the core instructions are front-loaded and readable.

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 prerequisites (API key), preparation (list_countries), the action itself, post-action status checking (get_waitlist_status), and behavioral side effects. Despite no output schema, the description effectively tells the agent what to do before and after, making the tool fully 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?

Schema coverage is 100% and already explains countryIsoCode constraints. The description adds extra semantics: the idempotent country-preference update and that the API key comes from register_agent, enriching the meaning of both parameters.

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 action: joining a waitlist for non-live countries, specifying eligible phases. It distinguishes itself from siblings like list_countries, get_waitlist_status, and dispatch_physical_task by clarifying when each is relevant.

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 usage context: use for countries in Closed, Roadmap, Alpha, or Beta phases, and directs the agent to call list_countries first and get_waitlist_status next. Implicitly contrasts with dispatch_physical_task for live countries, and states the API key prerequisite from register_agent.

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 mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: no authentication required, the exact phases and their meanings, and the workflow implications of the returned data. No contradictions with 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 front-loaded with purpose, then returns, then usage. Every sentence earns its place, including the note about waitlist influence. It is dense but not verbose, and structurally guides the agent through decision-making.

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 output schema, the description thoroughly covers return values and their semantics. It explains phase statuses, currency usage, the dispatch prerequisite, and the no-auth requirement. The tool's simplicity (no params) is fully addressed by a complete and actionable description.

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 input schema has zero parameters, so the baseline is 4. The description adds no parameter syntax but clarifies the output field 'currencyCode' and its importance, which is relevant to the consumer of this tool's results.

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 resource (all countries on Molt2Meet) and the action (list), and enumerates the returned fields including launch phase. It also differentiates from sibling tools like list_currencies and list_locales by focusing on country launch phases and workflow relevance.

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 to use this tool before dispatch_physical_task to verify Live status and obtain currencyCode, and explicitly says do NOT dispatch for non-Live countries, instead calling join_country_waitlist. This provides clear when-to-use and 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: 'No authentication required,' the default behavior of returning only Live-country currencies, and the exact counts (~130 entries). It does not cover rate limits or pagination, but for a read-only list tool this is sufficient.

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 front-loaded with the core purpose and then packs in necessary details. The dash-separated clauses make it slightly run-on, but every clause contributes meaning—no fluff. It's compact enough for the information it conveys.

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 list tool with one optional parameter, the description covers everything needed: purpose, default behavior, return fields (code, name, symbol, decimal places, zero-decimal flag, min/max amounts), and how to apply the results. There is no output schema, but the description compensates fully. No gaps remain.

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 a clear description for the includeAll parameter. The tool description adds further nuance by quantifying the default response ('typically a handful') versus the full list (~130 entries), reinforcing the parameter's effect 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 opens with 'List supported (Stripe-compatible) ISO 4217 currencies' — a specific verb and resource. It further distinguishes itself from sibling list tools (e.g., list_countries) by explicitly noting its purpose for payoutCurrency, making the tool's role unmistakable.

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 provides clear downstream usage: 'Use minPayoutAmount as the floor when setting dispatch_physical_task.payoutAmount.' It also explains the default vs. includeAll modes. However, it does not explicitly name alternative tools or state when not to use this tool, so it misses a full 5.

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 mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: no authentication required, the exact fields returned (URL slug, BCP 47 name, native display name, default flag), and how the slug relates to register_agent. No contradiction with 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 three sentences, front-loaded with the core purpose, and each sentence adds distinct value: what it lists, what it returns, and when to use it. No unnecessary fluff.

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?

Despite having no output schema, the description explains the return values sufficiently for an agent to know what to expect. It also covers authentication, usage timing, and the relationship to register_agent, making it complete for this simple, zero-parameter 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 tool has zero parameters, so the schema gives no parameter information. The description adds nothing about parameters because there are none, which aligns with the baseline 4 for zero-parameter tools.

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 function: 'List locales supported by the Molt2Meet platform.' It specifies the resource (locales) and the action (list), and distinguishes itself from sibling tools like list_countries and list_currencies by focusing on locale-specific data.

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 context: 'Use this before register_agent if you want to set a persistent language for payment pages and future localized responses.' This tells the agent when to use it, but does not mention when not to use it or alternatives, so it falls short of a 5.

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 indicate read-only and idempotent behavior. The description adds useful context beyond annotations: the status lifecycle, the polling use case, and the requirement for an API key from register_agent. This enhances transparency without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each delivering essential information: purpose, usage condition, statuses, prerequisite, and next step. No filler or 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 simple one-parameter list tool without an output schema, the description is fully complete. It covers what the tool does, when to use it, status progression, required API key source, and points to the detail tool for next steps.

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 apiKey described. The description reinforces this by specifying the key must come from register_agent, adding sourcing context that isn't in the schema. This goes beyond 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 lists all dispatched physical-world tasks with current status, using a specific verb and resource. It distinguishes itself from sibling tool get_physical_task_details by explicitly noting that it lists tasks, not details of a single task.

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 usage guidance: 'Use this to poll for progress if you did not provide a webhookUrl.' It also names an alternative for more detail: 'Next: get_physical_task_details for full details on a specific task.' This clearly explains when to use this tool vs. 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?

The annotations already establish read-only, non-destructive, idempotent behavior. The description adds beyond that by specifying that it shows pending, approved, and rejected requests, and explicitly requires authentication. This improves transparency without contradicting 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?

Two sentences, front-loaded with the main action, and no wasted words. The second sentence adds meaningful detail about result statuses and authentication, making it highly concise and well-structured.

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 and no output schema, the description covers the core behavior: lists all requests including statuses. It lacks pagination or ordering details, but for a straightforward list operation with clear parameter schema, it is sufficiently 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?

Schema coverage is 100% with descriptions for both apiKey and taskId. The description's mention of 'for a task' aligns with the taskId meaning but adds no syntax or additional semantics beyond the schema, so it meets 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 states 'List all reschedule requests for a task' with a specific verb and resource, clearly indicating the tool's function. It distinguishes from sibling tools like approve_reschedule and reject_reschedule by focusing on listing, and includes the scope of statuses shown.

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 clear context: use when you need to view reschedule requests for a task, and it mentions authentication as a prerequisite. It does not explicitly name alternatives or exclusions, so it misses the top score, but the usage is clearly implied.

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, and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: 'No authentication required' and the nature of the response content (pricing, duration, proof types), which helps the agent set 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 compact and front-loaded: it states the purpose immediately, then gives usage variations and a workflow hint. Every sentence adds value, with no redundant phrasing or unnecessary details.

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 read-only list tool with one optional parameter and no output schema, the description covers all necessary context: what it returns, how to use the parameter, authentication requirement, and the next logical step. It is fully complete for the agent to 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 already describes categoryId as an optional filter, but the description adds meaningful usage semantics: omitting it returns ALL capabilities and provides cross-reference to list_service_categories for valid IDs. This goes beyond the raw schema definition.

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 identifies the tool as listing detailed execution options (pricing, duration, proof types) for physical-world tasks, distinguishing it from siblings like list_service_categories and dispatch_physical_task. The verb 'list' and specific resource 'service capabilities' are concrete and unambiguous.

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 explicit usage guidance: omit categoryId to get all capabilities, pass categoryId (from list_service_categories) to filter, and use this before dispatching a task. It also names the next logical step (dispatch_physical_task), giving clear context on when and how to use the tool.

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 read-only, idempotent, and non-destructive traits. The description adds 'No authentication required' (an auth need) and 'Returns category IDs' (return-type hint), providing context beyond structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: purpose is front-loaded, followed by return usage and next steps. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple list tool with no params and no output schema. Description covers purpose, return hint, and usage guidance. Could specify exact output shape (e.g., array of category objects) but is sufficient for this trivial 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?

Tool has zero parameters, so there is nothing to document. Baseline for 0-param tools is 4; description correctly references downstream use of category IDs without needing parameter details.

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 starts with 'List available categories of physical-world tasks' – a specific verb and resource. It distinguishes from siblings by noting category IDs for dispatch_physical_task or add_service_interest and referencing list_service_capabilities.

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 'Any real-world task can be dispatched even without a category' (when-not), and provides alternatives: 'Next: list_service_capabilities for detailed options, or dispatch_physical_task to dispatch 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?

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: the authentication requirement (API key) and that only the caller's registered interests are returned. This is useful behavioral 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 extremely concise: one sentence stating the action and one sentence specifying a prerequisite. No unnecessary words, front-loaded with the primary purpose.

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 read-only list tool with no output schema, the description is complete. It states what is listed, the scope ('your registered'), and the required API key. The annotations cover safety, and the single parameter is fully documented in 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?

The schema already describes apiKey as 'Your Molt2Meet API key' with 100% coverage. The description adds semantic value by specifying the key must come from register_agent, which helps the agent understand the parameter's origin and prerequisite.

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 lists all registered service interests for the caller. The verb 'list' and resource 'service interests' are specific, and the scope 'your registered' distinguishes it from write tools like add_service_interest and other list tools like list_service_categories.

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 a prerequisite (API key from register_agent) but does not explicitly state when to use this over alternatives or exclude other tools. The context is clear enough to infer usage, but no explicit guidance is 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?

Beyond the readOnlyHint, destructiveHint=false, and idempotentHint annotations, the description adds useful context: wallets are created automatically on first use and authentication is required. This enriches the safety profile.

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 front-loaded with the main action and each sentence adds value: scope, auto-creation, use case, alternative tool, and auth requirement. No wasted words.

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 list operation with one parameter and no output schema, the description covers purpose, scope, behavior, and related tools. It is fully self-contained.

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 schema already describes the single parameter apiKey completely (coverage 100%). The description adds no extra parameter semantics beyond requiring authentication, 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 description uses a specific verb and resource: "List all your wallets across all currencies with balance details." It clearly distinguishes from sibling get_wallet_balance by specifying the multi-currency scope.

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 explicitly states when to use: "Use this to see which currencies you have funds in" and provides an alternative: "For a single currency, use get_wallet_balance instead." This is direct guidance.

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?

The description reveals significant behavioral consequences beyond annotations: funds are frozen, platform investigation triggers, settlement outcomes (refund/payout/compromise), resolution time (1-3 days), and authentication requirements. Annotations are minimal, so this context is valuable and does not contradict them.

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 dense but every sentence adds value: purpose, when-to-use, mechanism, resolution timeline, escalation path, reason codes, auth, and next step. It is well-structured and front-loaded, with no filler.

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 mutating action with no output schema, the description is exceptionally complete. It covers the full behavioral lifecycle: trigger, freeze, investigation, settlement types, timing, escalation, and follow-up monitoring. Nothing critical 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?

Schema coverage is 100% with descriptions for every parameter, including the reason code mapping. The description repeats the codes and adds a cross-reference ('same as reject_task_review'), which is marginally useful but largely redundant with the schema. 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?

The description opens with 'Open a formal dispute on a task', clearly stating the verb and resource. It also distinguishes from siblings by referencing reject_task_review and submit_support_request, making its role unambiguous.

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 conditions ('you believe the operator's claim is unjustified, the proof is fraudulent, or there is breach of contract') and typical invocation context ('typically called after reject_task_review'). Also gives an escalation alternative via submit_support_request with specific parameters, clearly guiding tool selection.

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?

The description goes beyond the annotations by revealing important side effects: for escrow Draft tasks, it automatically reserves and locks funds from the wallet and requires sufficient balance; for direct-settlement Draft, it explicitly states no funding happens. It also mentions the requirement for authentication and the follow-up event, providing a complete picture of the operation's behavior without contradicting any annotation flags.

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 lengthy but well-structured, starting with a clear one-sentence summary and then branching into mode-specific details. Each sentence carries essential information without redundancy, and the logical flow (status requirements -> per-mode behavior -> post-publish follow-up) makes it easy to parse. The front-loaded purpose sentence ensures quick comprehension.

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 is quite complete for a complex mutation tool, covering preconditions, side effects, and next steps. Given the absence of an output schema, the description adequately explains what happens, though it doesn't explicitly address idempotency (calling publish on an already-published task) or the exact status transition naming. The annotations already cover idempotency, so this is a minor gap. Overall, it provides sufficient context 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?

The input schema already provides high coverage (100%) for both apiKey and taskId, so the baseline is 3. The description adds meaning beyond the schema by stating that taskId must reference a task in Draft or Funded status, and that apiKey must be authenticated. This gives the agent a better understanding of the valid parameter values and preconditions, though it doesn't elaborate on error formats or return types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Publish a task to make it visible to operators.' It clearly distinguishes the tool from sibling tools like fund_task or request_task_quote by detailing that it works for both escrow and direct settlement modes, and the different states (Draft vs. Funded) where it applies. The title 'Publish Task' is expanded with concrete outcome and mode-specific behavior, leaving no ambiguity about its function.

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: the task must be in Draft or Funded status, and it works for both settlement modes. It also explains the direct-settlement shortcut versus the escrow flow, contrasting with fund_task and other related operations. It provides clear next steps ('wait for task.accepted via get_task_events or webhook'), giving the agent actionable guidance on post-publish workflow.

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?

The description discloses that the API key is shown only once and must be stored securely, and it explains callback behavior for OpenClaw agents. These details add valuable context beyond the annotations, which only indicate non-read-only and non-destructive behavior, without contradicting them.

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 relatively long but well-structured: it covers purpose, API key security, OpenClaw-specific guidance, a prerequisite legal step, and next steps. Each sentence adds meaningful information, so the length is justified rather than 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?

Despite having no output schema, the description explains the return value (API key) and its importance, plus the prerequisite call to get_legal_documents and suggested next actions. For a tool with 14 parameters, this provides a complete enough context for correct invocation, especially since the remaining details are in 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?

The input schema has 100% description coverage with rich details, so the baseline is 3. The description adds extra guidance for OpenClaw-related parameters (agentFramework, callbackUrl, callbackSecret) with example values, which provides supplementary value and helps the agent select the correct parameters for a specific use case.

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 'Register to dispatch physical-world tasks' with a specific verb and resource. It distinguishes from sibling tools by mentioning the API key returned for subsequent tools, which is unique to registration and not covered by other tools like dispatch_physical_task or get_agent_profile.

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 sequencing: 'Before registering, call get_legal_documents' and 'Next: dispatch_physical_task to dispatch a task, or list_service_categories to explore options first.' This gives clear when-to-use context and next steps, though it does not explicitly state when not to use the tool (e.g., if already registered).

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, destructiveHint=false, and idempotentHint=true. The description adds useful context by stating the authentication requirement and the decision-making scenario ('you disagree'), which goes beyond annotations without contradicting them.

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 two sentences, front-loaded with the action, and every word earns its place. No fluff or repetition.

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 mutation with 3 well-described parameters and annotations covering idempotence and safety, the description is largely sufficient. It could mention the outcome or side effects of rejection, but the core purpose and usage are clear.

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 all three parameters (apiKey, taskId, rescheduleId) are fully documented. The description does not add additional parameter meaning, but the baseline of 3 applies because the schema already covers 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?

The description uses a specific verb ('Reject') and resource ('a reschedule request'), clearly stating the action. It distinguishes itself from sibling tools like approve_reschedule and request_reschedule by focusing on rejection.

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 explicit context: 'Use this when an operator has requested a reschedule and you disagree.' It does not explicitly name alternatives like approve_reschedule, but the usage scenario is clear and the context suffices.

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?

Beyond the annotations (which are all false/neutral), the description discloses key behavioral outcomes: funds are frozen pending resolution, the operator can contest via dispute, and authentication is required. It could add more about the final state of the task or response format, but the provided context is significant.

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, starting with the critical 'ESCROW FLOW ONLY' warning, then explaining the action, preconditions, consequences, alternative, and authentication in exactly five sentences. Every sentence delivers necessary information 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?

For a mutation tool with no output schema, the description covers important business context: preconditions, fund freeze, dispute option, and alternative tool. It does not describe the response format, but given the richness of the context provided, the overall picture is fairly 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?

The input schema already provides full descriptions for all parameters (100% coverage). The description adds context about the escrow flow and preconditions but does not introduce parameter-specific semantics beyond what the schema offers, so the baseline of 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?

The description clearly states the tool rejects a completed task in the escrow flow, with specific preconditions (UnderReview status, settlementMode='escrow'). It explicitly distinguishes itself from the sibling 'dispute_direct_settlement_task', making the purpose unmistakable.

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 explicit when-to-use guidance: 'ESCROW FLOW ONLY' and the requirement that the task be in UnderReview status with settlementMode='escrow'. It also gives a direct alternative for direct-settlement tasks, which is exactly what the usage guidelines dimension requires.

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 indicate readOnly=false, so mutation is known. The description adds a valuable behavioral detail: 'If the request was waiting for your input, it will automatically move back to in_progress.' This is beyond what annotations or schema convey. It does not disclose all side effects (e.g., notifications), but given annotation coverage, this is solid.

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 informative sentences, front-loaded with purpose, then usage, then a behavioral note. Every sentence earns its place; no verbosity or filler.

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 covers purpose, usage scenarios, and a key side effect. Sibling context (get_support_requests, submit_support_request) further clarifies its role. Not exhaustive (no error conditions or closed-request behavior), but adequate for the tool's complexity.

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 covers 100% of parameters with descriptions, so baseline is 3. The description adds minimal extra meaning, e.g., 'follow-up message' maps to body and 'logs/evidence' hints at attachmentJson. No significant semantic enhancement 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 uses a specific verb ('Add a follow-up message') and clearly identifies the resource ('existing support request'), distinguishing it from sibling tools like submit_support_request (creates new) and get_support_requests (reads). This is a clear, unambiguous statement of purpose.

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 use cases ('provide additional context, respond to questions, or add logs/evidence') and implies when not to use it (e.g., for creating new requests). It does not name alternatives explicitly, but the context is clear enough to guide an agent. Lacks an explicit exclusion or 'when not to use' clause, so not a 5.

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?

The description discloses rich behavioral details beyond the minimal annotations: it creates a Pending reschedule entry, does NOT immediately change the task, requires operator approval, and explains counter-reschedule flow. This is exactly the context an agent needs to understand side effects and async behavior.

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 long but every sentence adds necessary information about preconditions, mechanism, parameters, or next steps. It is well-structured and front-loaded with the core purpose, though slightly dense; a modest reduction in wording could improve readability without loss of detail.

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 (7 parameters, async approval flow, no output schema), the description is remarkably complete. It covers preconditions, required input combinations, effect on the original schedule, operator actions, and suggested follow-up tools, leaving little ambiguity about how and when to use 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?

Although schema coverage is 100%, the description adds crucial semantic constraints: 'Provide at least one of: newTimeWindowStart/End (range), newRequestedTime (preferred time), newCommittedTime (firm commitment)' and explains the yyyyMMddHHmmss format. This goes beyond the bare schema descriptions by grouping related parameters and clarifying requirements.

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 'Propose a new time window for a task', a specific verb+resource that clearly states the function. It also distinguishes from sibling tools like approve_reschedule, reject_reschedule, and list_reschedules by emphasizing that it only creates a pending request.

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 explicit preconditions (rescheduleAllowed=true) and clearly states when not to use the tool. It also gives alternative/next steps: 'Next: list_reschedules to verify status, or wait for operator response via get_task_events', which helps the agent decide between this and related actions.

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?

The description richly explains behavior beyond annotations: the platform calculates split fees, returns a fee breakdown and wallet status, and lists fallback actions if balance is insufficient. It also notes authentication requirements and error conditions. This far exceeds the sparse annotation data (all hints false).

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 dense but every sentence adds value. It opens with a critical warning, then clearly sequences the action, preconditions, mechanism, return data, fallback options, and next steps. No fluff or 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 the tool's complexity (multi-step funding flow, preconditions, fallbacks), no output schema, and minimal annotations, the description provides a complete operational picture. It covers prerequisites, error cases, response contents, alternatives, and follow-up actions, leaving little ambiguity for an 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?

The schema already covers both parameters with clear descriptions (100% coverage), so the baseline is 3. The description adds meaningful context by specifying that taskId must reference a task in Draft/Quoted status with payoutAmount and settlementMode='escrow', and that apiKey is the authentication mechanism. This goes beyond simple schema text.

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 function: 'Request a fee calculation for a task — first step of the escrow funding flow.' It uses a specific verb ('request') and resource ('task quote'), and distinguishes itself from direct-settlement tasks and sibling tools like fund_task and publish_task.

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 explicit when-to-use and when-not-to-use guidance: escrow flow only, preconditions (Draft/Quoted status, payoutAmount set, settlementMode='escrow'), and warnings against calling on direct-settlement or already-funded tasks. It also names alternatives (FundViaPsp, checkout_wallet_deposit, get_bank_transfer_details) and next steps (fund_task, publish_task).

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 indicate idempotent and non-destructive behavior. The description adds 'Requires authentication' and the requirement to provide a decision as JSON, which are useful. However, it does not disclose potential side effects or what happens after resolution, leaving some behavioral aspects unspecified.

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 short sentences that front-load the core purpose and provide essential input format and auth requirements. Every word earns its place, with no repetition or filler.

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 action tool, the description covers the essential action and input, but it lacks details about return values, validation constraints, or the downstream effect of the resolution. Annotations fill some safety gaps, but the description alone is adequate yet 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 coverage is 100%, with all four parameters described. The description's mention of 'JSON string' adds no significant meaning beyond the schema's 'agentDecisionJson' description, so the baseline score 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 description uses the specific verb 'Answer' with the resource 'pending decision request', clearly distinguishing it from sibling tools like get_decision_requests. It also specifies the input format (JSON string), making the purpose unambiguous.

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 when there is a pending decision request to answer, but it does not explicitly state when to use this tool versus alternatives, mention prerequisites (e.g., first retrieving requests via get_decision_requests), or provide exclusions. Context is inferred but 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?

The description adds significant behavioral context beyond the annotations: the revocation is permanent, requests using the revoked key are immediately rejected, and the self-revocation limitation is disclosed. This complements the destructiveHint and idempotentHint annotations without contradicting them.

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 short sentences convey all necessary information without redundancy. The first sentence states the core action, the second explains the effect and timing, and the third covers the critical usage constraint. No wasted words.

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 fully covers the tool's purpose, usage context, prerequisites, and a key operational caveat. With annotations already conveying destructive and idempotent hints, and a simple two-parameter schema, this description leaves no critical 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?

The schema already covers both parameters with clear descriptions (100% coverage). The description reinforces the constraint on apiKey and adds a provenance note ('Requires: API key from register_agent'), providing extra meaning beyond the schema's basic definitions.

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 ('Permanently deactivate') and identifies the exact resource ('API key by its database ID'), making the tool's function unambiguous. It clearly differentiates itself from sibling tools like create_api_key by focusing solely on revocation.

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 rotating to a new key via create_api_key') and provides important exclusions ('You cannot revoke the key you are currently authenticating with in the same call'). It also names a prerequisite (API key from register_agent), which is clear guidance for correct 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 only false hints in annotations, the description carries the burden. It discloses that it returns a request ID for tracking and implies the request is storable by referencing get_support_requests. However, it does not mention authentication requirements (though apiKey is in schema), idempotency nuances, or any side effects besides creating the request, so it adds limited 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 two sentences (or three if counting 'Next:' as separate) with no wasted words. It is front-loaded with the action and purpose, then adds return value and follow-up guidance, earning 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?

Given 10 parameters and 100% schema coverage, the description does not need to explain each parameter. It provides the return value (request ID) and next-step tools, which is sufficient for a submission tool. It lacks explicit handling of edge cases like duplicate submissions or auth prerequisites, but these are not critical for the core use case.

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 the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema already provides (e.g., type, message, subject). The only extra info, 'Returns a request ID,' is output, not parameter-related.

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 verb and resource ('Submit a support request, complaint, or recommendation') and lists specific use cases. It differentiates from siblings by mentioning follow-up tools (get_support_requests, reply_to_support_request), making its scope distinct.

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 to report issues, request help, file complaints, or suggest improvements,' giving clear when-to-use guidance. It also points to next-step tools but does not explicitly distinguish from the related 'open_task_dispute' sibling or state when not to use it, so it falls short of a 5.

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?

The description adds substantial context beyond annotations: it mentions HMAC signing, rate limiting, and required authentication. While readOnlyHint=false and idempotentHint=true provide some hints, the description enriches the agent's understanding with specific operational behavior, though it does not detail response behavior or full side effects.

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 providing distinct value: purpose, technical behavior, rate limit, and prerequisite. No redundant or filler content. The description is front-loaded with the primary purpose.

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 two-parameter tool with no output schema, the description covers purpose, prerequisites, rate limiting, and authentication details. It leaves no significant gaps for an agent to invoke it 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 schema descriptions already fully cover apiKey and taskId (100% coverage), so the description adds little new parameter-level meaning. It reinforces that taskId must reference a task with webhookUrl configured, but this is already in 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 sends a 'test webhook event (webhook.test)' to verify endpoint configuration, using a specific verb and resource. It distinguishes itself from siblings like update_task_webhook by explicitly mentioning the prerequisite of configuring webhookUrl and webhookConfigJson via that 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?

It explicitly instructs users to configure webhookUrl and webhookConfigJson first via update_task_webhook, providing a clear alternative and prerequisite. The rate limit (3 per 5 minutes) also guides when repeated testing is appropriate. This gives strong usage direction.

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 indicate mutation (readOnlyHint=false) and idempotency (idempotentHint=true). The description adds that authentication is required and that the update is partial ('only provide the fields you want to change'), which implies merge semantics beyond what annotations convey.

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 concise sentences cover purpose, field behavior, precondition, and authentication. Every sentence adds value, with no redundancy or filler.

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 schema fully documents all parameters and annotations cover safety and idempotency, the description is nearly complete. It lacks mention of the return value, but with no output schema this is not critical. The guidance to read first and the partial-update semantics are sufficient for confident 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 coverage is 100%, so the baseline is 3. The description adds meaningful context that all fields are optional and only specified fields are updated, clarifying the patch-like behavior beyond the schema's nullable/default annotations.

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 'Update your profile' with a specific verb and resource, distinguishing it from read-only tools like get_agent_profile and creation tools like register_agent. The purpose is immediately unambiguous.

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 explicit guidance: 'Use get_agent_profile first to see current values' and clarifies that all fields are optional, so only changed fields should be provided. This gives clear when-to-use and sequencing instructions relative to sibling 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?

The description adds substantial behavioral context beyond the annotations: it discloses that geocoding is re-run, that the address becomes locked after operator acceptance, and that publishImmediately can trigger auto-publish/fund ladder with side effects (direct tasks publish immediately, escrow tasks auto-fund or return auto_publish_deferred with next_actions). This goes well beyond the simple idempotentHint/destructiveHint flags, and no contradictions exist.

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 dense but well-structured: a clear lead sentence, then precondition, lock warning, use case, publishImmediately behavior, and a practical summary. Every sentence earns its place, though the publishImmediately explanation is a bit lengthy. It remains readable and front-loaded with the primary purpose.

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 (preconditions, status restrictions, publishing side effects, no output schema), the description covers all essential aspects: return fields, geocoding re-run, status requirements, lock behavior, publish/fund ladder, authentication, and a concrete example of when to use it. It is complete enough for an agent to invoke the tool safely and 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%, so baseline is 3, but the description enriches key parameters: it explains publishImmediately's auto-publish/fund ladder, recommends providing 'house number and postal code' for locationAddress to get a rooftop match, and clarifies that locationLatitude/Longitude are optional overrides. This adds meaning beyond the raw schema definitions, though not every parameter is individually expanded.

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 explicitly states the action: 'Update the location of a Draft task' with specific behavior 'Re-runs geocoding and returns new resolvedLocation, geocodingConfidence, and location_warnings.' It clearly distinguishes from siblings by citing the use case for correcting location_warnings/low-confidence matches and the publishImmediately flow that parallels dispatch_physical_task.

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 explicit when-to-use guidance: 'Use this when the initial dispatch returned location_warnings or low confidence' and when not to use: 'Once an operator has accepted the task, the address is locked — cancel the task and recreate it.' It also states the precondition (Draft or Published status) and the publishImmediately option for correcting a typo and going live in a single call.

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?

The description discloses the partial update behavior ('Only provided fields are updated') and notes the authentication prerequisite, adding value beyond the annotations. While annotations already indicate idempotency and non-destructive behavior, the description provides useful context about when to supply auth config, which is not visible in structured data.

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 four sentences long, front-loaded with the primary purpose, and every sentence provides necessary information. It is concise without sacrificing clarity, and there is no filler or 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 the tool's moderate complexity (4 parameters, no nested objects, no output schema), the description adequately covers the purpose, usage, partial update behavior, and authentication nuances. It does not explain return values or side effects, but for an update tool with idempotency annotations, this is sufficient. A perfect score would require more explicit statements about consequences, but none are critical.

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 schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by explaining that webhookConfigJson is specifically for auth (e.g., when receiving 401), and reinforces the meaning of webhookUrl as the delivery endpoint. This contextual nuance goes beyond the schema, warranting a 4.

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: 'Update webhook settings for a task.' It specifies the resource (webhook settings) and the action (update/configure), and distinguishes itself from the sibling test_task_webhook by focusing on updating rather than testing. The scope is unambiguous.

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 clear usage context: when to configure webhookUrl and/or authentication, and explicitly says to provide webhookConfigJson when the endpoint requires auth. It also notes the partial update behavior ('Only provided fields are updated'). However, it does not explicitly mention alternatives or when not to use this tool (e.g., for testing), so it falls just short of a 5.

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