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

With no annotations, the description carries the full burden. It discloses the return format (one ParseResult per backend with latency, byte counts, error state, metadata) and notes it is a diagnostic tool, which suggests a read-only, non-destructive operation. However, it does not mention potential cost/performance implications of running all backends, nor does it clarify whether it modifies anything (though diagnostic implies it does not).

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 the primary action front-loaded. It is efficient and avoids redundancy. Every sentence adds value: the first states the operation, the second clarifies it as diagnostic and details the output.

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 a single required parameter, and the description fails to explain what that parameter is. While the output structure is partially described (ParseResult fields), the input format is a critical gap. The description also assumes the agent knows what 'backend' means, though sibling tool list_backends may help. Overall, this is incomplete for safe invocation.

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

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

The schema has no description for the 'source' parameter and schema_description_coverage is 0%, so the description must explain it. The description never mentions 'source' or what input is expected. The phrase 'same input' is generic and does not clarify that 'source' is the document to run through backends. The agent has no basis to know what to provide.

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, specific function: 'Run every available backend on the same input, compare results.' It also explicitly adds the word 'Diagnostic tool,' reinforcing its role as a comparison/benchmark rather than a typical parser. This distinguishes it from siblings like parse or parse_url, which are single-backend operations.

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 labels the tool as diagnostic and explains what it does (runs all backends and compares), which implies use cases like performance or correctness comparison. However, it does not explicitly say when NOT to use it or name alternatives (e.g., 'use parse for a single backend'), so the guidance is implicit rather than explicit.

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 behavior. It mentions the automatic selection of chunkers based on document structure and the token thresholds for splitting/merging. However, it does not detail error conditions, edge cases, or what happens when doc_type is invalid. The behavior of auto-detection is noted but not elaborated sufficiently.

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, two sentences, with the core purpose front-loaded. It introduces the key concept of auto-detection and the doc_type override efficiently. No unnecessary filler.

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

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

Given the tool's complexity (multiple doc types, token thresholds) and the presence of an output schema, the description is adequate but not rich. It explains the core behavior but omits details about how doc_type influences output, what 'retrieval-ready' implies, and potential errors. The output schema likely covers return structure, but more context on chunker selection logic would improve completeness.

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

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

The input schema covers all parameters with 100% description coverage, including defaults and constraints. The description adds only a minor note about file handling (via parse) that is also in the schema. It does not compensate beyond what the schema already provides, 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?

Description states a specific verb ('chunk') and resource ('markdown document') with a clear output goal ('retrieval-ready pieces'). It also mentions the doc-type-aware chunker selection, which distinguishes it from siblings like parse or detect_doc_type. The purpose is unambiguous.

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

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

The description implies usage (chunking text) and hints at pre-processing via the parameter note about parse, but it does not explicitly contrast with alternatives or state when not to use it. It offers some guidance through the doc_type parameter but lacks explicit usage context relative to sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool runs heuristics and returns a resolved doc_type token, which is adequate for a detection tool. However, it doesn't add context about edge cases (e.g., undetectable type, empty text) or the meaning of 'resolved' — a read-only detection tool could still clarify fallback behavior, so a 3 is appropriate.

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

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

The description is compact and front-loaded with the primary purpose, followed by the usage context and return value. Each sentence contributes information with no wasted words. The structure could be improved by explicitly tying the parameter to the heuristic input, but overall it is efficient.

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 an output schema present, the description doesn't need to detail return values, and it explains the purpose, use case, and behavior adequately for a single-parameter tool. Minor gaps remain around edge-case behavior and the exact meaning of 'resolved,' but the tool is simple enough that the description is nearly 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 0%, so the description must compensate for the undocumented `text` parameter. The description only implies that 'text' is the document being analyzed — it never explicitly states what the parameter represents or its expected format. With the schema providing zero guidance, this is a real gap that a sentence like 'text: the document content to analyze' would fill.

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

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

The description states a specific verb-resource pair ('detect document type') and explains the mechanism ('structural heuristics'). It also explicitly positions itself relative to the sibling tool chunk_text as a pre-chunking check, making it distinguishable from the other siblings without opening schemas.

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 a clear use case: 'Useful when you want to know what chunk_text would pick before actually chunking.' This names the relevant sibling and the condition that selects this tool. However, it doesn't explicitly state when NOT to use it or mention other alternative tools, so it falls just short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the two-step process (parsing and Claude reading), the caching behavior, and the cost optimization ('free input tokens'). However, it does not explicitly state that the tool is read-only (implied but not stated), nor does it mention error handling, rate limits, or potential side effects. For a tool that presumably only reads and answers, this is adequate but not fully 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 concise and well-structured. The first sentence states the core purpose, the second gives usage examples, and the third explains the workflow and caching. Every sentence earns its place with no fluff. The information is front-loaded with the core functionality.

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

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

Given the tool's moderate complexity, 100% schema coverage, and the presence of an output schema, the description is quite complete. It explains the internal workflow, caching benefits, and the type of requests it handles. The output schema presumably covers return values, so the description need not repeat those. It does not detail supported source formats or error cases, but these are likely covered by the backend parameter and output schema. Slight gap on edge cases, but overall adequate.

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 does not add any parameter-specific information beyond what the schema already provides. While the examples hint at 'source' and 'instruction', the schema itself already describes each parameter (model, source, backend, max_tokens, instruction) clearly. The description adds no additional semantic depth.

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: 'Parse the document, then ask Claude over the parsed markdown.' It specifies the verb (parse and ask) and the resource (document), and the examples ('summarize this PDF', etc.) solidify the purpose. It implicitly distinguishes itself from parsing-only siblings like 'parse' and 'parse_url' by adding the Claude interrogation step.

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 directly tells the agent when to use the tool with 'Use this for... style requests' and provides concrete examples. It also explains the internal workflow (router parses, then Claude reads) and caching benefits. However, it does not explicitly state when NOT to use it or mention alternative tools (e.g., 'if you only need the parsed text, use parse'), leaving some inference to the agent.

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

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

With no annotations provided, the description must carry the behavioral burden. It discloses the output format ('a list of {name, available, module} entries') and implies it is a read-only diagnostic operation (no side effects are mentioned). This is sufficient for a simple listing tool, though it does not describe edge cases or error handling, which are minor for this type of function.

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

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

The description is two sentences, front-loading the purpose and return structure first, then adding a practical usage example. Every word earns its place; there is no filler or redundancy. It is concise yet 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?

For a zero-parameter tool with an output schema (flag true), the description provides all needed context: it explains what the tool returns, why it exists (debugging backend availability), and how it relates to the router fallback scenario. The agent can correctly invoke and interpret the result without additional documentation.

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

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

The tool has zero parameters, so the baseline is 4. The schema (empty object) already fully documents that no arguments are needed. The description reinforces that by focusing entirely on output and usage, adding no unnecessary parameter details. This 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 what the tool does: reports which parse backends are installed and which are missing. It specifies the resource ('parse backends') and the action ('Report') and differentiates it from sibling tools like parse or parse_url, which actually perform parsing rather than inspecting backend availability. The return shape is also given, 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 gives a concrete use case: 'Use this to debug "why did the router fall back to markitdown" by checking whether docling/llamaparse are actually available.' This tells the agent when this tool is appropriate (diagnosing fallback behavior) and implicitly distinguishes it from parsing tools. It does not explicitly mention when *not* to use it or name alternatives, but the context is clear enough for a zero-parameter utility.

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 provided, so the description must carry the behavioral disclosure burden. It mentions automatic routing but this repeats the schema's backend parameter description. Nothing about error behavior, side effects, or required permissions.

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

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

Two short sentences with the primary purpose front-loaded. No wasted words, effectively minimal.

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 but lacks details on error handling, supported document types, or distinctions from siblings. The schema and output schema provide some context, but gaps remain for an agent deciding whether to use this tool.

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

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

Schema coverage is 100% and the description adds no parameter-specific information. Baseline 3 applies since the description doesn't need to compensate but also doesn't add value.

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?

States a specific verb (convert), resource (document), and output (markdown). The routing note distinguishes it from specialized siblings like parse_url.

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 explicit guidance on when to use this vs parse_url or parse_to_vault. The routing comment implies a default use case but doesn't state exclusions or alternatives.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states the tool writes markdown to the vault, includes audit trail in frontmatter, and matches the output shape of the script. It does not contradict any annotations (none exist) and adds meaningful context about the output format and the router integration, though it does not cover error handling or side effects beyond what the schema already implies.

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 waste. The primary purpose is stated first, followed by the replacement context and key behavioral difference. It is front-loaded and efficient, making it easy for an agent to parse quickly.

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 presence of an output schema and full parameter schema descriptions, the description provides sufficient overarching context: what it does, where it writes, and what the output contains. It could mention prerequisites (e.g., file accessibility) or failure modes, but these are secondary given the schema details. Overall it is fairly complete for an agent to call 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 all parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds no additional meaning about specific parameters, only an overall behavioral context (e.g., audit trail in frontmatter) that indirectly relates to the 'backend' parameter but does not explain how to use it. Since the schema already documents each parameter clearly, this 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 states a clear, specific action ('Parse a document and write it to the vault as a markdown note') with a specific resource and destination. It further distinguishes the tool by noting it replaces a standalone script and adds an audit trail, so an agent can tell it apart from generic parse tools like 'parse' or 'interpret'.

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

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

The description implies the primary use case (persisting parsed output to the vault) and explicitly references the replacement of a shell script, which gives context. However, it does not explicitly compare with sibling tools like 'parse' or 'parse_url' or state when to prefer this over them. The guidance is present but not fully explicit.

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 only states 'shortcut' and 'same return shape as `parse`' without disclosing any behavioral details such as validation, error handling, or how it processes malformed URLs. This is completely insufficient for an AI agent to predict the tool's 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 extremely concise, consisting of two short sentences. It front-loads the primary purpose and immediately references the return shape. Both sentences earn their place, but the brevity borders on under-specification, so it is not a perfect 5.

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?

An output schema exists, so the return type is defined, but the description lacks crucial details: it does not explain the purpose of the `backend` parameter, does not elaborate on what 'parsing' entails, and does not clarify the relationship to `parse` beyond the shared return shape. The tool is simple, but the description leaves too many gaps.

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

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

The schema has zero descriptions (0% coverage), so the description must compensate. It adds a constraint that the `url` parameter should be an HTTP(S) URL, which is useful. However, it entirely fails to explain the `backend` parameter, leaving the agent without a full understanding of the input parameters.

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

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

The description clearly states the operation (parsing) and resource (HTTP(S) URL). It references the sibling `parse` to indicate a variant, but does not explicitly explain the difference beyond calling it a 'shortcut'. This is clear enough to distinguish it from generic tools, though the distinction from `parse` is implicit.

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

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

The description implies it is for URL inputs but never explicitly states when to choose this tool over `parse` or other siblings. It only says 'Same return shape as `parse`', which provides minimal context but does not offer explicit when-to-use or when-not-to-use guidance.

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