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 idempotency, behavior on already-finished jobs, the resulting status, and the quota impact. This level of transparency exceeds what is typical and is genuinely useful for an agent.

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 tightly structured with clear sections: action, idempotency, use cases, exclusions, and return value. Every sentence earns its place, and key information is front-loaded. 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 covers purpose, use when/not, return value, and side effects (quota impact). No output schema exists, but the return behavior is explicitly described in both normal and edge-case scenarios. It is complete for an agent to make an informed call.

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 baseline is 3. The tool description does not add parameter-specific details beyond the schema, but it reinforces the job ID format and context instructions. Since the schema already fully documents both parameters, the description need not compensate.

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 and resource: 'Cancel a queued or running ingest job.' It clearly distinguishes this from sibling tools like get_ingest_job, list_ingest_jobs, and start_ingest, leaving no ambiguity about the operation.

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 'Use when' and 'Do NOT use when' sections provide concrete criteria and name an alternative tool (update_watcher) for the paused-watcher case. This is the gold standard for 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?

With no annotations provided, the description carries the full burden and exceeds it. It discloses the lossless-first pipeline, metadata stripping while preserving ICC/EXIF, best-effort target_size_kb behavior, rejection of animated APNG/WebP, the guarantee of never being larger than input, and the authoritative file-size return. This is comprehensive 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?

Though lengthy, every sentence earns its place. The structure is logical: core behavior, input rules, compression algorithm, explicit use/non-use cases, and return value interpretation. It is front-loaded with the essential 'keeps its format' message and includes no filler 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?

Given the tool's complexity (5 parameters, no output schema), the description is fully complete. It covers accepted input extensions and URL/path rules, unsupported formats, return payload (presigned URL, metadata, jobId), how to verify target_size_kb, and the optional save_to behavior. Nothing important is left unsaid.

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 descriptive text adds semantic depth beyond the schema: it explains the two-phase compression algorithm (lossless first, then downscale with aspect ratio locked), clarifies that target_size_kb is best effort and unreachable targets are not errors, and notes that save_to writes locally. This pushes it above baseline.

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

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

The description opens with 'Shrink an image FILE while KEEPING its format' – a specific verb, resource, and constraint. It clearly distinguishes itself from convert_image by stating 'this tool is a size optimizer and NOT a format converter,' which differentiates 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?

There is an explicit 'Use when' section with concrete examples (compress, make smaller, under 200 KB, optimize for web) and a 'Do NOT use when' section that names convert_image as the alternative for format conversion, SVG rasterization, unsupported extensions, and notes no tool supports PDF/document compression. This is exemplary 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?

With no annotations provided, the description fully carries the behavioral disclosure burden. It reveals that the server downloads bytes rather than rendering web pages, rejects unsupported extensions, preserves headings for RAG suitability, returns a presigned URL plus metadata and jobId, and supports optional local saving via save_to. This is transparent and actionable.

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

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

The description is well-organized with a clear summary sentence, a detailed but scannable 'Use when'/'Do NOT use when' breakdown, and a final return-value note. Every sentence adds distinct information without redundancy, making the length justified.

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 no annotations, the description is remarkably complete: it lists all 22 accepted extensions, explains the return values (presigned URL, metadata, jobId), describes optional save_to behavior, and gives explicit exclusion criteria. An agent has enough context to invoke the tool correctly in a variety of situations.

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%, baselining this at 3. The description adds meaningful nuance beyond the schema by clarifying that a URL input must point directly at the file ('server downloads the bytes, it does NOT render web pages') and that relative paths are rejected, which helps the agent select valid inputs.

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 statement: 'Convert almost any document FILE to one heading-aware Markdown (.md) file.' It names the exact verb, input type, output format, and distinct resource. It also differentiates from sibling tools like convert_anything_to_pdf and perceive_url in the 'Do NOT use when' section, 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 includes explicit 'Use when' and 'Do NOT use when' lists. It names specific alternatives: perceive_url for live web pages, convert_anything_to_pdf for PDF output, convert_document for HTML/data formats, and it clearly states that image/OCR input is not accepted. This is ideal guidance for 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?

With no annotations, the description carries the full burden and does so thoroughly: it lists all 36 accepted extensions, discloses that PDF inputs are passed through, describes the return shape (presigned URL, metadata, jobId), and details the pdf_options caveat that geometry options only apply to certain input types, with a 400 rejection for unsupported combinations.

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 front-loaded purpose and clear section headers, and every major piece of content is useful. However, it is somewhat longer than necessary because format lists like images, SVG, and RTF appear both in the 'Use when' examples and again in the overlap explanation, creating mild redundancy.

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

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

Given no output schema and no annotations, the description is remarkably complete: it covers input path/URL, accepted extensions, return values, exclusions, alternatives, and pdf_options limitations. The only omission is explicit sync/async behavior, but the jobId return value strongly implies asynchronous processing.

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 baseline is 3. The description adds meaningful value beyond the schema by explaining the pdf_options geometry caveat and the absolute-path requirement, but it does not enrich every parameter; save_to and output_filename rely mostly on their 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 opens with a specific verb and resource: 'Convert almost any FILE to PDF' and explicitly frames the tool as a catch-all endpoint. It distinguishes itself from convert_document, convert_image, perceive_url, and convert_anything_to_markdown by describing its unique 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 provides explicit 'Use when' and 'Do NOT use when' sections, including named alternatives (perceive_url, convert_document, convert_anything_to_markdown) and clear reasoning for when the catch-all is preferable. It even explains the deliberate overlap with convert_document and which side of that overlap to choose.

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 so well: it discloses URL download behavior (server downloads bytes, does not render web pages), unsupported pairs fail instantly with valid output list, output_format defaults to 'pdf', and return value includes a presigned URL plus jobId. A minor gap is not explaining the jobId lifecycle/polling, but overall transparency is strong.

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

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

The description is longer than typical but each sentence carries substantive information: conversion pairs, exclusions, use cases, and return details. The 'Use when'/'Do NOT use when' structure and clear paragraph breaks make it easy to scan. No filler or redundancy, though it could be slightly tightened without losing clarity.

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

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

For a complex tool with no annotations and no output schema, the description is remarkably complete. It covers input types (path or URL), all supported conversions, unsupported pair behavior, default output_format, return value structure, save_to usage, and pdf_options. It also provides clear alternatives, making it sufficient 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 description coverage is 100%, so baseline is 3. The description adds value by enumerating exact supported format pairs, which implicitly defines valid output_format values, and by clarifying that pdf_options affect only PDF outputs. This goes beyond the schema's generic examples and default notes.

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 'Convert a document FILE between formats' and provides an exhaustive list of supported conversion pairs, distinguishing it from siblings like convert_image and perceive_url. The verb+resource is specific and the explicit pair list eliminates ambiguity about 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 includes explicit 'Use when' and 'Do NOT use when' sections, naming alternatives such as perceive_url for live web pages, convert_image for image conversions, and convert_anything_to_pdf/markdown for EPUB. This is exemplary guidance on when to choose this tool versus 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 carries full burden and succeeds: it discloses multi-page PDF ZIP vs single-page JPEG, PDF output_format 'jpeg'-only with instant failure, presigned URL + metadata + jobId return, SVG-only width/height behavior, and the 25-megapixel cap for SVG rasterization.

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 well-structured and front-loaded with the core conversion scope. Each paragraph has a clear role (overview, use cases, exclusions, returns), and every sentence carries operational information, though some length could be trimmed without losing meaning.

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

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

With no output schema and 7 parameters, the description supplies all essential context: valid formats, input types, return value shape, save_to behavior, SVG sizing rules, and sibling-tool boundaries. An agent can confidently select and invoke this tool without further clarification.

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%, but the description still adds substantial meaning: file can be an absolute path or http(s) URL with relative paths rejected; width/height are SVG-only and describe proportional scaling; output_format is restricted to jpeg for PDF input; save_to writes locally. This exceeds the baseline expected at full 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 precise verb-resource pair: 'Convert an image FILE between formats' and enumerates exact format combinations. It distinguishes convert_image from siblings by explicitly covering image/SVG/PDF rasterization, while naming convert_document, compress_image, and convert_anything_to_pdf as the tools for other cases.

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?

There are explicit 'Use when' and 'Do NOT use when' sections with concrete alternatives: document formats -> convert_document, live web pages -> perceive_url, size-only reduction -> compress_image, PDF output -> convert_anything_to_pdf. This makes the selection criteria unambiguous.

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

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

With no annotations provided, the description carries the full burden of disclosure. It states credential-free operation, hard cadence floor, notification channels (email/webhook), quota gating, and return structure — far exceeding typical transparency.

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

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

The description is dense but well-structured: purpose first, then use/when-not-use, then return behavior. Every sentence earns its place, and the 'Use when' / 'Do NOT use when' pattern is highly scannable for an agent.

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 7 parameters, no annotations, and no output schema, the description covers selection criteria, constraints, return values, and failure mode (quota gate). It is fully self-sufficient for an agent to decide when to invoke and what to expect.

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 beyond the schema by explaining diff_mode strategy selection and reinforcing the minimum frequency constraint. It does not duplicate the schema's per-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?

The description starts with a specific verb+resource: 'Monitor a URL for changes' with details on cadence, diffing, and notifications. It clearly distinguishes itself from sibling tools like perceive_url by explicitly calling out the one-time snapshot 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?

Provides explicit 'Use when' and 'Do NOT use when' guidance, including concrete use cases like price/stock monitoring and competitor tracking. It names the alternative tool (perceive_url) and states a hard constraint (60-minute minimum cadence), making selection trivial.

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

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

With no annotations provided, the description fully discloses key behaviors: soft-delete semantics, idempotency, monitoring stoppage, post-deletion HTTP 404, non-reversibility via API, and the returned tombstoned watcher with status 'deleted'.

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: a short opening sentence, then purpose-based bullets for when to use, when not to use, and the return value. Each sentence serves a distinct purpose 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?

The description covers all essential aspects for a deletion tool with no output schema and no annotations: intent, side effects, irreversibility, alternatives, and return behavior. It is self-sufficient 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 both parameters (watcher_id and context) with detailed descriptions, achieving 100% schema coverage. The tool description adds no parameter-specific detail, but the schema already provides the necessary meaning, 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 opens with a specific verb and resource: 'Delete a watcher (soft-delete, idempotent).' It clearly distinguishes this from siblings by noting monitoring stops and the watcher reads as 404 on get_watcher, which is unique to deletion.

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 provides 'Use when' and 'Do NOT use when' guidance, including a concrete alternative (update_watcher with status 'paused') and the irreversible nature of deletion. This makes the decision boundary crystal 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?

Without annotations, the description carries full burden; it discloses key limitations: no page rendering, HTTP-only crawl, no JS-rendered links, and no render quota consumption. It also explains the hybrid mode. It stops short of discussing rate limits or target-site impact, but the disclosures are strong.

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

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

The description is well-structured with labeled sections, front-loads the core action, and every sentence adds value. It avoids fluff and is 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?

Given the tool's complexity, the description covers the essential context: what it does, when to use it, what it returns, and its limitations. The 'Returns' section compensates for the lack of an output schema, and the 'Do NOT use' section preempts misuse.

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 all 9 parameters with descriptions (100%), so the baseline is 3. The description adds only a passing mention of include/exclude regex patterns, but doesn't materially enhance the parameter 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 opens with a specific verb ('Enumerate') and the resource ('website's URLs'), and explicitly contrasts with page rendering, which differentiates it from sibling tools like perceive_url. It also clearly scopes what it returns (URLs 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?

The description includes explicit 'Use when' and 'Do NOT use when' sections, naming concrete scenarios (e.g., before perceive_batch/extract_structured/start_ingest) and alternatives (perceive tools for contents, web_search for open web). This is clear guidance on 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?

No annotations are provided, so the description carries the full burden. It discloses the two-pass engine (CSS first, LLM escalation), plan-gating, guarantee of output shape, per-URL extraction_tier, field provenance, cost reporting, and failure isolation — significant behavioral detail beyond typical descriptions.

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 structured with clear sections (overview, use when, do not use, returns) and each sentence adds distinct value. Despite its length, it avoids redundancy and remains scannable.

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 8 parameters and no output schema, the description explains the return format, error isolation, cost reporting, and edge cases (50 URL limit). It also covers alternative tools and prerequisites (schema format), making it nearly self-sufficient.

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 description adds essential semantics to the schema parameter by specifying accepted formats (JSON-Schema or flat map) and explains the relationship between urls and discover_from. Other parameters (wait_for, wait_timeout_ms) lack description integration, but with 63% schema coverage, the description compensates well for the core 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 opens with a specific verb and resource ('Extract structured data matching YOUR schema from up to 50 URLs'), clearly stating the core function. It explicitly distinguishes the tool from siblings by naming perceive_url and start_ingest as inappropriate alternatives.

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

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

The description includes explicit 'Use when' and 'Do NOT use when' sections with concrete examples ('get every product's name and price from these pages') and named alternative tools (perceive_url, start_ingest, ingest). This leaves no ambiguity about when to select this 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It lists specific return fields (status, pages, total_chunks, output_url, error_message, webhook state), notes that output_url is signed and only available once completed, and mentions timing behavior. It doesn't state side effects, but for a read-style getter 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 organized into three short sections—purpose, usage guidance, and return summary—each earning its place. It front-loades the core purpose and remains succinct while providing actionable 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?

With no output schema and no annotations, the description compensates by detailing return values and polling expectations. It also handles tool selection by naming alternatives. A minor gap is not explicitly stating that the tool is safe/read-only, but the overall coverage is strong for a simple getter.

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%, with job_id and context both documented. The description repeats only the job_id format ('ing_...') and does not add new meaning beyond the schema. Baseline score of 3 is appropriate 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 'Get one ingest job by job_id (ing_...)' which is a clean verb+resource+identifier format. It further distinguishes from siblings by explicitly naming get_perceive_batch and get_watcher as alternatives for different ID types.

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 'Use when' and 'Do NOT use when' sections provide clear context for polling and fetching output_url, plus explicit alternatives for perceive batches and watchers. The polling cadence guidance (5-30 s per page) adds operational value.

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 exist, yet the description discloses the three possible return states, the polling implication ('poll again shortly'), and the recovery scenario (timeout/dropped connection) that motivated the call. It also tells where to find jobId from prior conversion results.

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 labeled sections (Use when / Do NOT use when / Returns) convey everything in under 100 words, with zero 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 status-check tool with no output schema, the description fully specifies input provenance, decision rules, return semantics, and alternatives. Nothing needed 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 already covers both parameters with descriptions, so the baseline is 3. The description adds the crucial provenance: job_id is the jobId embedded in every successful convert_document/convert_image result, and context is for analytics. This adds semantic value 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?

Description opens with a specific verb ('Check') and resource ('status of ONE file-conversion job by job_id'), and explicitly differentiates from sibling tools (get_perceive_batch, get_ingest_job) by stating what it does NOT do. This leaves no ambiguity about 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?

Contains explicit 'Use when' and 'Do NOT use when' sections naming alternatives (get_perceive_batch, get_ingest_job) and an exclusion condition (no jobId at hand). This is textbook 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?

With no annotations provided, the description fully carries the transparency burden. It discloses polling behavior, that artifact URLs are freshly signed on each poll (implying rotation/expiry), timing expectations, and return contents. It lacks details on failure modes or terminal statuses, but the core polling behavior is well covered.

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

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

The description is extremely concise at ~80 words, yet covers polling mechanics, usage guidance, alternatives, and return values. Each sentence serves a distinct purpose and the structure is front-loaded with the core action, followed by when/not-when and returns.

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 polling tool with 2 parameters and no output schema, the description is remarkably complete. It explains the return payload (aggregate status/counts, ZIP artifact, per-URL results), operation timing, and disambiguates from related tools. No significant gaps remain for an agent to use the tool correctly.

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

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

Schema coverage is 100%, with clear descriptions for both job_id and context. The tool description adds little beyond the schema: 'Poll a perceive batch by job_id' essentially restates the parameter's purpose. It does not provide additional format, constraints, or examples, so 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 explicitly states 'Poll a perceive batch by job_id', a specific verb and resource. It also distinguishes from sibling tools by specifying when NOT to use it (for single operation_id or ingest job), naming the correct alternatives get_perceive_operation and get_ingest_job.

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 clear 'Use when' and 'Do NOT use when' clauses, noting conditions (after perceive_batch returns 'queued' or 'processing') and expected timing (5-30 s per URL). Explicitly names alternative tools for misuse cases, making guidance actionable.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the return shape (same as perceive_url with freshly re-signed URLs), the 404 error behavior, and the 15-minute URL expiry context. It falls short only by not explicitly stating read-only semantics or potential rate limits, but it is otherwise transparent.

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, with clear section breaks (Re-fetch, Use when, Do NOT use, Returns). Every sentence serves a distinct purpose, and there is no redundant or filler content.

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 get-by-ID tool, the description covers the trigger conditions, the expected return shape (referencing perceive_url), and the error case. It is fully self-contained for an agent to invoke correctly without needing to infer additional behavior.

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 value by clarifying that operation_id must be a perceive operation ID (per_...) and not a job or batch ID, which prevents common mistakes. The context parameter is already fully described in the schema, so no further elaboration 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 a specific verb 'Re-fetch' and resource 'perceive operation by its operation_id', clearly distinguishing it from siblings like get_perceive_batch. The mention of 'per_...' ID format further clarifies the target.

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 'Use when' scenarios (expired signed URLs, re-reading results) and a 'Do NOT use' clause that names the alternative tool (get_perceive_batch) and the wrong ID types (job/batch ID). This is textbook 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?

No annotations are provided, so the description carries the burden. It discloses a key edge case: 'Deleted watchers read as 404.' It also specifies return content ('full watcher configuration and lifecycle timestamps'). While it doesn't explicitly state read-only behavior, the name 'get' and scope make it obvious. This is substantial disclosure for a simple getter.

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 tightly structured: a one-sentence summary, a 'Use when'/'Do NOT use when' pair, and a 'Returns' clause. Every sentence contributes unique value, with no redundancy or filler. It is front-loaded with the core action and 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 single-resource getter, the description is fully complete. It states the input identifier, the output (full configuration and lifecycle timestamps), an edge case (404), and usage boundaries. The absence of an output schema is compensated by the explicit return description. Sibling context confirms this is sufficient.

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 both parameters are already well-documented. The description adds little beyond schema: it reiterates 'by watcher_id (wat_...)' which is already in the schema. The context parameter is fully specified in the schema with detailed instructions. Baseline 3 is appropriate because the description doesn't supplement parameter meaning.

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 one watcher by watcher_id (wat_...).' It distinguishes from siblings by implying it retrieves a single watcher's configuration, contrasting with list_watchers and get_watcher_snapshots. The specific mention of watcher_id format and the 404 behavior for deleted watchers further clarifies 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?

Explicit guidance is provided: 'Use when: checking a watcher's full configuration and schedule state' and 'Do NOT use when: the change history is wanted (use get_watcher_snapshots).' This gives clear context and names an alternative tool, satisfying the when-to-use and when-not-to-use criteria.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses ordering ('newest first'), return shape ('snapshots [{checked_at, has_changes, similarity, change_count, changes[]}]'), and a security consideration ('Change values are raw page content, so treat as untrusted'). It also notes the diff entries are bounded. This covers safety/context well, though it could add details about permissions or failure modes.

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

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

The description is well-organized into purpose, usage guidance, and return format, with each sentence providing distinct value. It is concise but not terse, and the structure makes it 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?

Although there is no output schema, the description explicitly lists the return fields. It gives use cases, exclusions, and sibling references. Given the tool's moderate complexity and fully described parameters, this is a complete and self-contained 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?

Schema description coverage is 100%, so the baseline is 3. The schema already describes watcher_id, limit, and context. The description does not add additional parameter semantics beyond what the schema provides, but it also does not need to because the schema is complete.

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 specifies the tool's function: 'Read a watcher's check history, newest first' with specific output elements (has_changes, similarity, bounded diff entries). It explicitly distinguishes from get_watcher by stating 'Do NOT use when: only the watcher's config/schedule is needed (use get_watcher)', which positions it against 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 provides explicit 'Use when' and 'Do NOT use when' sections, naming concrete scenarios ('what changed on that page', 'verifying a watcher is actually checking') and a direct alternative tool (get_watcher). This gives the agent clear decision criteria.

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

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

With no annotations provided, the description carries the full burden and does well by disclosing ordering (newest first), pagination behavior (skip/limit, has_more), and the specific fields returned (status, page counts, chunk count, output_url when done, webhook flags). It does not mention rate limits or auth, but for a read-only list operation this is arguably 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 tightly structured into four short, purposeful sentences: what it does, when to use it, when not to use it, and what it returns. Every sentence earns its place 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 list tool with no output schema and no annotations, the description is remarkably complete. It explains the tool's purpose, usage scenarios, exclusions, and return shape (including the paging flag), enabling an agent to select and invoke it correctly without needing 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?

The input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by explicitly tying skip/limit to pagination and mentioning the 'has_more' paging flag, giving the agent a clearer understanding of how these parameters affect the 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 clearly states the tool's function: 'List the project's ingest jobs, newest first, with pagination (skip/limit).' It specifies the verb (list), resource (ingest jobs), and key behaviors (newest first, pagination), distinguishing it from the sibling tool get_ingest_job.

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: 'Use when: finding a job_id, reviewing recent jobs, or checking several jobs at once' and explicitly names the alternative for single known jobs: 'Do NOT use when: one known job (use get_ingest_job).' This clearly directs the agent to the appropriate 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?

With no annotations, the description carries full responsibility. It discloses return format (compact rows with specific fields), ordering, pagination, and has_more. It doesn't explicitly state read-only safety or error behavior, but for a list operation 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 concise and well-organized with clear sections: action, use cases, non-use case, and return summary. Every sentence adds value without redundancy.

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

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

For a paginated list tool, the description covers purpose, usage boundaries, and return contents. Since there is no output schema, the return description is sufficient. Complexity is low, and no critical 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%, so parameter descriptions already document skip and limit. The description mentions pagination but adds no new semantic detail 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 lists project watchers with specific details: ordering, pagination, and the inclusion of has_more. It distinguishes itself from get_watcher explicitly, which helps the agent choose correctly.

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 'Use when' scenarios (finding a watcher_id, reviewing monitoring, auditing health) and 'Do NOT use when' (single known watcher) with a named alternative (get_watcher). This is exactly the guidance needed.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the inline vs queued behavior based on batch size, instructs to poll get_perceive_batch with the job_id, and details the return payload (job_id, status, per-URL counts, full perceive result). It also discloses that some extract targets are not implemented and return a warning, and that output_mode 'zip' bundles artifacts. This is thorough and beyond what the schema provides.

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

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

The description is well-structured with clear sections for behavior, use cases, and exclusions. It is front-loaded with the core batch behavior, and every sentence adds value—no filler. The length is justified given the tool's complexity, and the structure aids 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?

Given the tool's complexity (17 parameters, nested objects, asynchronous behavior), the description covers all critical aspects: batch limits, polling mechanism, return structure, use-case selection, and exclusions. Combined with the 100% schema coverage, an agent has everything needed to decide when to use this tool and how to handle its async nature. No significant 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 description coverage is 100%, so the baseline is 3. The description adds some context about the shared options block and the zip bundling behavior, but it does not deeply elaborate on individual parameters beyond what the schema already states. It appropriately relies on the schema for parameter details, so a 3 is warranted.

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 and resource: 'Render up to 1000 URLs with one shared options block.' It immediately distinguishes itself from siblings by mentioning batch vs single URL and explicitly naming alternatives like perceive_url and start_ingest. The purpose is specific 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 provides both 'Use when' and 'Do NOT use when' conditions with named alternatives for each exclusion: perceive_url for single URLs, start_ingest for RAG-ready chunked output, and discover_urls/web_search for unknown URLs. This is exactly the guidance an agent needs to choose 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?

No annotations are provided, so the description carries the full behavioral burden, and it succeeds: it discloses caching (~1h), signed-URL expiry, inline markdown truncation (~256 KB), chrome-stripping defaults, and the partial-implementation warning for some extract targets. It also makes the read-only nature clear by describing rendering/capturing rather than mutating state.

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 justified by the tool's complexity (16 parameters, many artifact types). It is front-loaded with the core purpose and uses labelled sections for usage and exclusions. Minor redundancy exists where only_main_content behavior is restated from the schema, but it reinforces a default that agents often get wrong.

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 no output schema and no annotations, this description covers selection criteria, return metadata, URL expiration/re-signing, output semantics, cache behavior, and parameter interactions. An agent has everything needed to choose this tool over siblings and invoke it with correct artifact/parameter combinations.

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 coverage is 100%, so the baseline is 3, but the description adds meaningful inter-parameter semantics: which outputs fit which user goal, how pdf_options relates to the 'pdf' output, how schema pairs with 'structured' extraction, and how only_main_content alters markdown behavior. This goes beyond the schema's isolated field comments.

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 'THE tool for live web pages' and an explicit verb-resource pair: 'Renders one URL in a real browser and returns... artifacts.' It differentiates itself from siblings by naming what it is not (file conversion, search, batching, ingestion) and by cataloguing its artifact outputs.

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 a concrete 'Use when' section mapping user intents to output choices, and an explicit 'Do NOT use when' section with named alternatives (convert_document, convert_image, web_search, perceive_batch, start_ingest). An agent receives direct routing guidance with no inference required.

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

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

With no annotations provided, the description takes on the burden of disclosing behavior. It states that the tool re-delivers a webhook, lists return fields, and mentions failure conditions. This is thorough, though it could have added note about idempotency or side effects of repeated deliveries.

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, front-loaded with the main action, and uses short bullet-like lines for conditions and return values. Every sentence adds value 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 retry operation with a simple parameter set and no output schema, the description covers the core scenario, prerequisites, error handling, and return values. It is self-contained and sufficient for an agent to use the tool correctly.

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

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

Both parameters have descriptions in the schema with 100% coverage, so the description doesn't add parameter information. The baseline applies because the schema already fully documents job_id and context.

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

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

The description opens with a specific verb and resource: 'Re-deliver the completion webhook of a COMPLETED ingest job.' This clearly distinguishes it from sibling tools like get_job_status or cancel_ingest_job, which serve different purposes.

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

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

Explicit guidance is provided with 'Use when' and 'Do NOT use when' sections, including concrete conditions such as webhook_delivered is false, and error cases like 409 (job not completed) and 400 (no webhook_url). This leaves no ambiguity about appropriate invocation.

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 asynchronous queued behavior, immediate return of job_id, polling/webhook options, HMAC-signed completion, signed output_url, and credential-free rendering. This is a comprehensive behavioral 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?

Three compact paragraphs: function, usage guidance, return contract. Every sentence adds distinct value and the most critical information is front-loaded.

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 15-parameter async job tool with no output schema, the description explains the job lifecycle, output retrieval (signed link), and how to get results (poll or webhook). It also addresses credential-free rendering and spawns context. This is complete enough for an agent to invoke confidently.

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 80% and most parameters carry adequate descriptions in the schema. The tool description adds high-level parameter context (up to 1000 URLs, modes, webhook) but doesn't deeply elaborate beyond 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 a precise verb-object pair ('Turn a website ... into RAG-ready chunked JSONL'), specifies input modes (sitemap/crawl vs explicit URL list), and distinguishes the tool from siblings like perceive_batch and extract_structured. This makes it unmistakable what the tool accomplishes.

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 includes explicit 'Use when' and 'Do NOT use when' sections, naming alternatives (perceive_batch, extract_structured) and conditions (synchronous needs, handful of pages). This is exactly what agents need for 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?

With no annotations, the description carries full burden. It discloses partial-update semantics ('Send only the fields to change'), the webhook removal trick (empty string), a side effect (resuming re-checks watcher cap), and returns the updated watcher. Could add more on error behavior or permission requirements, but it's above average.

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

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

The description is well-structured with clear sections (behavior, usage, exclusions, returns). Every sentence adds value; 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?

For a tool with 8 params, nested objects, and no output schema, the description covers key aspects: return value, usage context, and notable side effects. It omits details on error cases and field formats, but overall 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 50%. The description adds value by explaining the update pattern (at least one field required), explicitly mapping fields (cadence, diff mode, etc.), and reinforcing the webhook_url empty-string behavior. It does not elaborate on track_fields structure, but compensates reasonably.

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 changes a watcher's settings (cadence, diff mode, tracked fields, webhook, email preference, status) with a specific verb 'Change'. It distinguishes from siblings by explicitly saying not to use it for removal (use delete_watcher).

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 'Use when' and 'Do NOT use when' guidance, naming the alternative delete_watcher and giving concrete use cases like pausing/resuming monitoring, tuning frequency, or changing notification targets.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the Google-backed nature, the optional auto-rendering behavior (perceive_top), that each perceive_top consumes a quota unit, and the expected return format (ranked results, answer box, knowledge graph, and full page content). This goes beyond a simple read-only claim and informs the agent of 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 concise yet structured, using clear 'Use when', 'Do NOT use when', and 'Returns' sections to break down the information. Every sentence earns its place, and the most critical information (what the tool does) is front-loaded.

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 has 11 parameters and no output schema, the description compensates thoroughly by outlining return types, filters, and the perceive_top integration. It covers what the agent would need to know to use the tool effectively, including quota implications, without being overwhelming.

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 each parameter having a description, so the baseline is 3. The tool description adds semantic value by explaining how parameters combine—for instance, that perceive_top collapses search-and-fetch into one round trip and that category includes six options. This is helpful context beyond 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 begins with a specific verb and resource: 'Search the web (Google-backed) in six categories: web, news, images, scholar, patents, maps.' It clearly distinguishes this tool from siblings like perceive_url and discover_urls by explicitly stating when not to use it, 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 provides explicit 'Use when' and 'Do NOT use when' sections, naming exact alternatives (perceive_url, discover_urls) and giving concrete use cases such as research requiring multiple page fetches. This offers clear guidance on when to choose this tool over alternatives.

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