Errand

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

The description goes beyond the destructiveHint annotation by disclosing that it refunds the escrow in full and that it fails once a worker has accepted, potentially while they are traveling. This gives the agent a complete picture of side effects and failure modes, with no contradiction to 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 with no fluff, front-loading the core action and then stating the key failure condition. It is easy to scan and 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?

For a simple one-parameter tool with destructive annotations, the description covers the action, refund, and failure condition. It does not describe the response format, but with no output schema that is acceptable. The tool is sufficiently complete for an agent to decide when and how to call 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 schema already fully documents dispatch_id as 'Id returned by errand_dispatch', and the description adds no additional parameter-specific meaning. With 100% schema coverage, 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 action (cancel) and resource (real-world human dispatch), and distinguishes it from sibling tools like errand_dispatch, errand_get_status, and errand_quote by specifying the cancellation and refund behavior. The condition 'while it is still open' adds precision and 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?

The description gives explicit usage conditions: it is valid only when the dispatch is still open and fails after a worker has accepted. This provides clear guidance on when to use the tool, though it does not explicitly name alternative tools. However, the sibling list makes the cancellation role obvious.

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 readOnly, idempotent, and non-destructive. The description goes beyond annotations by defining the two return categories ('reachable_workers... these get the push' and 'online_workers... app open this minute') and clarifies that this check happens 'before spending.' This adds meaningful behavioral context 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 two sentences, front-loaded with the core purpose, then the key return semantics, then concrete use cases. Every sentence adds value 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 there is no output schema, the description adequately explains what the tool returns and what the two worker categories mean. It names real-world usage scenarios and positions the tool within the spend flow. The missing radius/location semantics are a gap, but the overall context is sufficient for an agent to decide when to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, with lat and lng having no descriptions. The description does not compensate by explaining coordinate format, radius_m behavior, or how the three parameters relate to 'nearby' or 'physical location.' It only says 'physical location' at a high level, leaving 67% of parameters semantically undocumented.

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

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

Description opens with a precise verb and resource: 'Check whether a nearby human can be dispatched to a physical location before spending.' It is clearly distinct from siblings like errand_dispatch and errand_quote because it is positioned as the pre-spend availability check, and it names concrete use cases (photos, queues, pickups).

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 for on-site or store checks, photos, queues, pickups... when you need current human availability.' It implies the tool is a pre-dispatch/pre-spend check, but it does not explicitly say when not to use it or name an alternative such as errand_dispatch. This is strong context without formal 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?

Annotations already mark destructiveHint=true, but the description adds valuable behavioral context: it spends money, creates a real-world action, requires user confirmation, and describes payment/refund conditions (completed tasks pay worker; failed/expired/pre-acceptance cancelled refund escrow). This 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 four sentences and each conveys necessary information: action/use cases, mandatory quote step, execution/evidence, and financial outcomes. It is slightly dense but front-loaded and without 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?

Given the tool's complexity (12 parameters, 9 required, no output schema), the description covers the critical workflow and financial consequences. It does not detail all parameter requirements, but the schema covers many, and the description adequately explains the tool's real-world impact.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 58%, so the description carries some weight. It adds general context for reward 'spends money' and location 'nearby real human/physical location', but does not explain specific parameter semantics like task_type options, reward bounds, or expiry defaults, leaving gaps that the schema only partially fills.

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 action: 'Send a nearby real human to a physical location' and enumerates use cases (verification, checks, photos, queue, pickup). It distinguishes from siblings by explicitly requiring errand_quote first, which differentiates it from quote/cancel/status 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 gives explicit prerequisites: call errand_quote first, present its exact total_charge_krw, and obtain explicit user confirmation. However, it does not explicitly state when not to use the tool or name alternative tools for status/result retrieval, 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the agent knows this is a safe read operation. The description adds valuable context beyond those annotations by detailing what the result contains, including evidence provenance such as GPS distance, capture time, and server checks. It does not note behavior when the result is not yet ready, but this is minor for a read-only fetch.

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

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

The description is a single focused sentence with no filler. The verb and resource are front-loaded, and the trailing list is purposeful because it explains what the returned result contains.

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, single-parameter retrieval with no output schema, the description gives a comprehensive picture of the expected payload and provenance details. It could explicitly mention readiness conditions or how this relates to errand_get_status, but the core information needed to invoke the tool correctly is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the dispatch_id parameter is already documented as 'Id returned by errand_dispatch.' The description does not add further parameter-level semantics, but none are needed given the single, self-explanatory 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 opens with a clear verb and object: 'Retrieve the verified on-site result from a human task,' and then enumerates the exact contents (pass/fail verdict, score, feedback, signed photo URLs, structured answers, evidence provenance). This distinguishes it from siblings like errand_get_status, which presumably reports task state rather than the full verified result.

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 that this tool is for fetching final verified task results, but it never explicitly states when to call it versus errand_get_status or errand_dispatch. It provides no exclusions or alternative routing, leaving the agent to infer the correct usage 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that by listing the specific status values an agent should expect and mentioning the event timeline, which helps set expectations for the response shape.

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 focused sentences carry all necessary information: the status enumeration is front-loaded, and the usage timing is stated in a single follow-up sentence. There is no fluff or repetition of the schema or annotations.

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 single-parameter read-only status tool, the description covers what it does, when to call it, and what to expect in the response (status and event timeline). With no output schema, a brief mention of the return value would be nice, but the status list plus timeline is adequate for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: dispatch_id is already documented as 'Id returned by errand_dispatch.' The tool description reinforces this by calling the task 'previously dispatched' and saying to use it after errand_dispatch, but it doesn't add substantive new parameter-level meaning beyond the schema.

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

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

The description uses a specific verb ('Track') with a clearly scoped resource ('previously dispatched local human task') and enumerates the status values ('open · accepted · arrived · submitted · completed · failed · cancelled · expired'). This clearly differentiates the tool from siblings like errand_get_result, which would retrieve the eventual outcome rather than the live status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'Use after errand_dispatch while the person is traveling or working on site.' It names the correct predecessor and context, though it doesn't explicitly describe when not to use it or mention alternatives like errand_get_result.

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, covering safety. The description adds context beyond annotations by specifying that it reveals account-specific capabilities and constraints (supported task types, spend caps, allowed area, KRW balance, pricing), which are behavioral traits of the tool. The 'Read-only' at the end reinforces the annotations without contradiction. Since annotations cover the safety profile, the description's added context about what the tool reveals (e.g., account limitations) contributes value. Score 4 because it adds richer context than just repeating the annotations; it explains what the tool returns and its purpose in a pre-task 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 a single sentence that is front-loaded with the use-case trigger ('Use before a local-human or physical-world task'), followed by the specific resource contents, ending with 'Read-only.' Every word earns its place: it includes the trigger, the list of what is returned, and the safety hint. No filler or redundancy. Efficient 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 that there is no output schema, the description carries the burden of explaining what the tool returns, which it does effectively by listing the items. For a zero-parameter, read-only capability tool, it covers the essential information: when to use, what it tells you, and that it's read-only. It could mention that it returns results for the current account (implicit) or cost implications, but given the simplicity, 4 is appropriate. It doesn't explain response format, but the tool is arguably a simple capability query. A score of 4 reflects it's complete for its purpose; only missing minor details like exact response 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?

The input schema has zero parameters, so there are no parameters to document. The description doesn't need to explain parameters. A baseline of 4 is given for zero-parameter tools because the schema provides no parameter information. The description does not attempt to describe parameters (there are none), which is correct. It focuses on the output content. Score 4 aligns with the rule: '0 params = baseline 4' – it fully covers what an agent needs to know about parameters (there are none).

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 ('Use before a local-human or physical-world task') and names the resource ('Errand') and clearly enumerates what it returns: supported on-site task types, spend caps, allowed area, KRW balance, and pricing. It distinguishes itself from siblings by describing a capabilities/capability discovery tool, whereas siblings like errand_dispatch or errand_quote perform actions or estimations. The phrase 'to see what Errand can do for this account' frames it as a discovery capability tool, differentiating it from action-oriented 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 explicitly states when to use: 'Use before a local-human or physical-world task' – giving a clear contextual trigger. It lists the specific items it returns, which helps the agent determine if it needs this information. While it does not explicitly name sibling alternatives, the collective sibling list makes it evident that this is a pre-flight check, not an action. The guidance is clear and actionable, though it does not mention when NOT to use it, but the 'before a task' framing implies it's a prerequisite check, not a substitute for action 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's emphasis on 'read-only' slightly repeats annotations. However, it adds valuable details: validates account caps, live worker coverage, and balance, and specifies return fields (reward_krw, platform_fee_krw, total_charge_krw). This goes beyond annotations, especially for a read-only operation, but doesn't cover all behavioral aspects like error conditions or rate limits, which is acceptable given the annotation coverage.

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, front-loads the main verb and resource, and each sentence adds distinct value: the first states what it does and outputs; the second provides an actionable guidance. No fluff. Could be slightly more structured, but it's efficient and clear.

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 (5 params, no output schema), the description covers the key aspects: what it returns, what it validates (caps, coverage, balance), and the critical workflow step (obtain confirmation). With annotations covering safety and idempotency, and no output schema to define, the description is complete enough for an agent to call correctly. It doesn't need to explain return formats since there is no output schema, and the required parameters are evident.

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 low at 20%, only radius_m has a description. The description compensates by explaining the purpose of the tool and the key output parameters, but doesn't detail each input parameter (e.g., lat/lng meaning, task_type semantics). Since the schema provides clear names and enums, the description adds value by linking parameters to the quote calculation, but could be more explicit about edge cases or how radius_m affects the quote.

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 obtains a read-only quote for sending a human to a real-world location, listing specific task types (check, verification, photo, queue, pickup) and outputs exact amounts. It immediately identifies the tool's purpose as a quote estimator and distinguishes it from siblings like errand_dispatch and errand_check_coverage.

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 usage context: use to get a quote before dispatching, and explicitly instructs to present the total and obtain confirmation before proceeding to errand_dispatch. It doesn't explicitly state when not to use it (e.g., for checking coverage only, use errand_check_coverage), but the context of quote vs. dispatch is clear from sibling names.

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