DiffiCat

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

With no annotations provided, the description carries the full burden and does so well. It states the cancellation outcome, the timing ('reports cancelled within a minute'), and the partial-report behavior ('pages compared so far in its report'), giving the agent concrete 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 main sentence is concise and front-loaded with the action and key behavior. The trailing 'Free.' adds little operational value and could be considered noise, keeping this from 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?

For a simple cancellation tool with no output schema, the description covers the core outcome, timing, and report contents. It does not mention immediate return behavior or error cases, but the essential context for invoking the tool 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 only 50%; jobToken is documented but jobId is only given a pattern. The description does not explain the roles of these parameters or how they relate to the running job, so it fails to compensate for the schema gap.

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: 'Stop a running job,' which clearly identifies a cancellation operation. This distinguishes it from siblings like start_comparison (starting) and get_comparison/get_report (reading results).

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 indicates the tool is for stopping a running job, so the context of use is obvious. It does not explicitly rule out alternatives or describe when not to use it, but there is no competing cancel tool among the siblings.

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

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

With no annotations, the description must disclose key behaviors, which it does: the output format (full-page PNG), the dual return value (image plus jobId/jobToken), and the cost (USDC 0.02 USD per call). It does not mention side effects like rate limits, but for a read-only capture this is adequate.

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 extraneous words. The main purpose is front-loaded, followed by the return value and cost. Every sentence adds critical 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?

The description covers the core purpose, return value, and payment requirement, which are essential for an agent to call the tool correctly. It lacks details on potential errors or timeout behavior, but given the simplicity and schema coverage, 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 description coverage is 100%, so the schema documents all parameters. The description adds context about the overall function but does not elaborate on parameter specifics beyond what the schema provides. 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 clearly states the action ('Full-page PNG of one URL') with a specific resource and output type. It also distinguishes the tool from get_screenshot by explaining that it returns a jobId/jobToken for later retrieval, making its role in the workflow 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 context that this is the first step in capturing and then retrieving via get_screenshot, but does not explicitly state when not to use it or discuss alternatives like start_comparison. The relationship to get_screenshot provides sufficient guidance for common usage.

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

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

No annotations are provided, so the description carries the burden. It discloses the payment requirement (0.05 USD per call) and the method (sitemap, robots.txt, or crawl). However, it does not mention side effects, return format, or error handling, leaving gaps in 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 concise, consisting of two sentences. The main purpose is front-loaded, and the payment note is appended without unnecessary detail. 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 tool has 4 parameters and no output schema or annotations. The description covers the purpose, method, and cost, but does not specify the return format or error behavior. While the schema covers parameters, the description lacks some details that would make it fully complete 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?

Schema coverage is 100%, so all parameters already have descriptions. The description adds context about mapping Site A to Site B but does not provide additional syntax or format details beyond what the schema offers. Baseline 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 action ('List the pages of Site A') with a clear resource and optional mapping to Site B. It distinguishes itself from siblings like start_comparison and capture_screenshot, which handle different tasks, so an agent can easily tell it apart.

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 for when to use the tool: to discover pages from a site, optionally mapping to another. It does not explicitly mention when not to use it or name alternatives, but the sibling tools are clearly different in purpose, so the usage context is sufficiently 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?

With no annotations, the description must carry the behavioral disclosure burden, but it only states 'Status and progress of a job. Free.' It implies a read-only polling operation but does not explicitly say so, nor does it cover error behavior, authentication, or what the returned status means. 'Free' is ambiguous and adds little.

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 appropriately short and front-loads the core status/progress idea. However, the second sentence 'Free.' does not earn its place and reads as irrelevant noise. The brevity is good, but the content is under-specified.

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 annotations, no output schema, and only 50% parameter coverage, the description is far from complete. It omits required inputs, expected return values, failure modes, and how this tool relates to start_comparison or get_report. An agent would struggle to invoke it correctly without additional information.

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 50%: jobToken has a description, but jobId has only a regex pattern. The description adds no parameter meaning, fails to explain that jobId identifies the comparison job, and does not connect jobToken to the creation step. It therefore does not compensate for the schema's gaps.

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 'Status and progress of a job' only restates the title with less specificity, replacing 'comparison' with the generic 'job.' It does not state the resource or a direct retrieval verb, and it does not distinguish itself from siblings like get_report or get_screenshot, which are also job-related.

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?

No usage guidance is provided. The description does not say when to poll this tool after start_comparison, when to prefer get_report for final results, or what distinguishes status retrieval from cancel_comparison or get_screenshot. There is no when-to-use or when-not-to-use information.

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

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

With no annotations, the description carries the full burden and does disclose pagination behavior via offset, limit, and nextOffset, plus the returned report structure. It does not disclose error behavior, job-state requirements, or whether the operation is read-only, and the standalone 'Free.' is ambiguous.

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-loads the main purpose. The final 'Free.' is extraneous and ambiguous, which prevents a perfect score, but the rest of the text is dense and informative.

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

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

The description covers the response structure and pagination, which is essential for calling this tool. However, with no output schema and no annotations, it omits job-completion preconditions, error handling, and how this tool fits into the comparison workflow, making it adequate but incomplete for a no-annotation context.

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 documents limit, offset, and jobToken, but the description adds meaningful pagination context: the default 1000-per-call slice and that nextOffset points to the next slice. This clarifies the relationship between offset, limit, and the returned data 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 as returning a completed report with summary, per-page slices, and plain-text content. It lacks an explicit verb like 'retrieve' and does not explicitly distinguish itself from get_comparison, but the resource and scope are 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 word 'finished' implies the report is only available after a job completes, providing a weak contextual hint. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives like get_comparison or start_comparison.

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

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

No annotations are present, so the description must carry the burden. It only conveys that the result is a PNG and is 'Free'; it does not disclose credential requirements, side effects, error behavior, or whether an existing image is returned. No contradiction with annotations exists since none are provided.

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 one short sentence and is easy to scan. The 'Free.' fragment is an extra detail but does not significantly hurt concision; information is front-loaded with the result type.

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 and no annotations, the description should explain return behavior and usage context more fully. It omits what happens when a filename is invalid, why jobId/jobToken are needed, and whether the returned PNG is binary or a path. The tool may be simple, but the current text leaves an agent to infer key 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?

The schema already describes filename and jobToken, covering 67% of parameters. The description adds that the filename comes from the report or capture_screenshot, which clarifies the source of that parameter, but it does not explain jobId or jobToken beyond schema. This partial overlap yields a middling score.

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 identifies the result as 'A screenshot PNG' and ties it to 'the report or returned by capture_screenshot,' making it clear this retrieves an already-produced screenshot rather than creating one. However, no explicit verb like 'retrieve' or 'fetch' is present; the noun-phrase description leans on the tool name for action.

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 'named in the report or returned by capture_screenshot' suggests the tool is used after report generation or a capture, which gives some context. It does not explicitly state when to prefer this tool over capture_screenshot or list alternatives/exclusions, so guidance is only 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?

No annotations are provided, so the description carries the full burden. It discloses the upfront USDC charge, per-page pricing tiers, the fact that maxPages is a ceiling not a reservation, and the absence of a page limit. It also notes that omitting targetUrl captures screenshots of Site A only, adding behavioral 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 four sentences, front-loaded with the primary purpose, then pricing, then maxPages nuance, then workflow. Every sentence contributes new information with zero 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 tool with 9 parameters, nested objects, and no output schema, the description covers the key aspects: purpose, pricing, parameter interplay, and follow-up workflow. It does not mention error cases or explicit auth requirements, but those are implicit in the schema. Overall, it gives an agent enough to invoke the tool correctly.

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

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

Schema coverage is 100% and each parameter already has a useful description. The description adds value by clarifying the interaction between urls and maxPages (pricing on compared pages, maxPages as a ceiling) and the overall pricing semantics, going beyond the individual parameter 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 a specific verb-resource pair: 'Compare Site A against Site B on page existence, content and visual regression.' This distinguishes it from siblings like capture_screenshot and discover_pages by naming the comparison objective and the two sites involved.

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 workflow guidance ('Poll get_comparison, then get_report') and explains the pricing model, but it does not explicitly contrast with alternatives or state when not to use it. The purpose is obvious, so context is clear, but exclusions or explicit sibling routing are absent.

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