veritap

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. Beyond that, the description adds valuable context: it explicitly states the tool is free, read-only, has no side effects, and discloses that every request is recorded and analyzed in aggregate. It also promises an 'honest answer when it cannot' corroborate, which is useful open-world nuance.

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: first sentence states the purpose, second gives when-to-use and return behavior, third covers privacy. It has minimal filler, though it slightly repeats the annotation's read-only hint. Overall it is 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?

With no output schema, the description adequately summarizes what the tool returns: 'whether it can be corroborated from sources today, what evidence would come back, and an honest answer when it cannot.' It also explains the purpose, usage conditions, and privacy implications. It does not detail the unsupported-claim callback flow, but the schema covers the callback_url parameter, so the description is reasonably complete for a tool of this 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?

The input schema has 100% coverage with detailed descriptions for all 9 parameters, so the description does not need to explain each one. The description adds no per-parameter semantics beyond what the schema already provides, which fits the baseline of 3 for high schema coverage.

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: 'Check whether a fact can be corroborated before your task depends on it.' This clearly sets it apart from sibling tools like check_feasibility or check_physical_condition by focusing on source corroboration of an inferred fact, not on other kinds of checks.

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 an explicit trigger: 'Use when a step rests on something you have only inferred from text and being wrong would be expensive.' This establishes when to use the tool and implicitly tells the agent not to use it for facts that are already directly stated. It does not name alternatives among sibling tools, so it stops short of the highest score.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond that: 'Free, no auth, read-only, no side effects' (partially repeats annotations), 'Never errors,' and 'Every request is recorded and analysed in aggregate...' It also discloses that unsupported claims are logged. 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 about 120 words, with the core purpose in the first sentence and supporting usage/behavior details following. It is front-loaded and each sentence adds information. It could be slightly trimmed (e.g., the final privacy sentence), but it remains appropriately sized for a 9-parameter tool.

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

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

For a tool with 9 parameters, nested objects, and no output schema, the description covers purpose, usage, and behavioral traits well, but it does not describe the response format or what the answer contains (e.g., a boolean, a verdict object). It only mentions callback behavior for unsupported claims. This is a notable gap given the absence of an output 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; every parameter (claim_description, deadline, location, claim_type, callback_url, task_context, cost_if_wrong, downstream_action, budget_ceiling_usd) has a meaningful schema description. The tool description itself adds no parameter-specific detail beyond what the schema already provides, 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 states a specific verb+resource: 'Check whether a real-world fact can be verified before committing to a paid request.' It clearly distinguishes this from sibling tools by focusing on feasibility (can it be verified) rather than the verification itself, and it names concrete coverage areas ('businesses, listings, objects, and places').

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: 'Use speculatively: if any step of your task depends on a physical-world fact you cannot confirm... check here first' and 'call liberally during planning.' It also notes this should happen 'before committing to a paid request.' However, it does not explicitly mention sibling tools as alternatives or state when not to use this tool, 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?

Beyond the annotations, the description adds that the tool is free, read-only, and has no side effects, which aligns with the readOnlyHint and destructiveHint. It further discloses that every request is recorded and analyzed in aggregate, and clearly states its limitation of not performing physical inspections.

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: it states purpose in the first sentence, adds cost/safety in the second, gives usage guidance in the third, and explains returns/limitations and data handling in the fourth and fifth. Every sentence carries distinct 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?

Given the rich annotations and full schema descriptions, the description adequately covers the tool's purpose, usage, and non-obvious behaviors (data recording, no physical inspection). Since there is no output schema, the description does not need to explain return values. It lacks only explicit links to sibling alternatives, keeping it from a 5.

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 nine parameters have detailed descriptions in the schema (100% coverage), so even without additional parameter info in the tool description, the baseline of 3 applies. The description does provide high-level context (e.g., the purpose and limitations) but does not add parameter-specific 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 clearly identifies the tool's purpose with a specific verb ('check') and resource ('the stated condition, damage, or grading of a physical item or property'). The added 'Use when' sentence positions it distinctly from sibling verification tools by focusing on physical item condition claims.

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 ('when a decision depends on an item being in the condition a listing claims') and provides a key exclusion ('nobody is sent to look'), which implies when not to use it for physical inspections. However, it does not explicitly name alternative 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool is free, read-only, with no side effects, returns what can and cannot be corroborated, and that every request is recorded and used for aggregate feature decisions. This goes beyond the annotations and gives the agent a clear picture of the tool's behavior, though the 'no side effects' phrasing is slightly at odds with the recording note.

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, front-loaded with purpose and safety, with no filler. The privacy/analytics note is useful and the return behavior is summarized in one sentence. Every 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?

The tool has 9 parameters and no output schema, but the description covers the when, the what, and the shape of the return value (corroborated vs. not, self-settle guidance). The rich schema handles the parameters. It could have named alternative tools for non-purchase checks, but 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?

The input schema covers 100% of the 9 parameters with detailed descriptions, so the schema does the heavy lifting. The description adds no per-parameter syntax or format details, but this is not necessary at this coverage level; it does indirectly reference the unsupported-claim and callback workflow in prose. 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 uses 'Check whether a listing, item, or business can be corroborated before an agent commits money,' which names a specific action (corroborate/check), a specific resource class (listing/item/business/seller), and the monetary context. This clearly differentiates it from siblings like check_physical_condition or plan_verification.

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 to use it 'before any irreversible spend where the counterparty or the goods have only been seen online,' giving a concrete trigger condition. It does not compare to sibling tools by name, but the spending context is enough for an agent to select it over general-purpose 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?

Beyond annotations (read-only, idempotent, non-destructive), the description discloses free/no-auth usage, no side effects, and that every request is recorded and analyzed in aggregate. It also explains return behavior per step. This adds meaningful context beyond the structured hints.

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 earning its place: first states purpose and safety, second explains input and output, third discloses data use. It is front-loaded and free of 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?

With no output schema, the description compensates by explaining what is returned per step (checkable fact, claim type, remediation). It also covers data handling. For a 2-param tool, this is comprehensive, though it could specify output format details.

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

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

Schema has 100% coverage, so baseline is 3. The description adds value by advising to pass the whole plan including undecomposed steps, which clarifies how the 'steps' parameter should be used. The return description also ties parameters to expected output.

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 ('Map') and resource ('a multi-step plan against what can be grounded in the real world'), and clearly states the per-step output. It distinguishes itself from siblings by focusing on verifiability mapping rather than feasibility or purchase confirmation, making its role unique.

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 ('call liberally during planning') and instructs to include all steps, even undecomposed ones. However, it does not explicitly name alternatives or state when not to use the tool, 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?

Beyond annotations, the description discloses cost/speed ('Free, instant'), side effects ('no side effects'), and a data policy: 'Every request is recorded and analysed in aggregate to decide what gets supported next.' It also reveals the decision behavior of routing away self-settleable items. These behavioral traits significantly augment the readOnly/idempotent hints and do 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 three paragraphs and every sentence earns its place. The opening line front-loads purpose and key attributes, followed by a compact explanation of the triage output and a privacy note. No redundancy with 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?

With no output schema, the description explains the three output categories with attached metadata (suggested source, price/turnaround, planning advice). It covers return semantics adequately, though it doesn't detail the exact response structure or error handling, which would strengthen 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?

Schema coverage is 100%, so the parameters are well documented. The description adds practical guidance: batch all uncertainties in one call, and that structured objects with why_it_matters and if_unresolved get sharper triage. This goes beyond schema descriptions, providing actionable tips for parameter usage.

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 and resource: 'Triage everything you are uncertain about in one call.' The title amplifies this by naming the exact output categories (answerable, verifiable, or neither). It distinguishes itself from siblings by focusing on batch triage of uncertainties rather than verifying a specific claim.

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 context: 'call liberally during planning' and 'dump every uncertainty at once, mid-reasoning, before deciding which are worth chasing.' It implies when to use it relative to other tools (before verification), but does not explicitly name sibling alternatives. The guidance is clear enough for an agent to know to use this when facing multiple uncertainties during planning.

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