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

With no annotations, the description carries the full behavioral burden. It usefully reveals defaults (model, think, field_types inference) and the verify_pages fallback behavior ('默认零调用'). However, it does not disclose whether the operation is read-only, what the 'dual paths' actually are, or how errors or unsupported inputs are handled.

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 short intro, a version note, an Args list, and a Returns line. It is reasonably concise, though internal jargon such as '信号②', 'M3，T03', and '触发规则' adds noise without aiding an agent's decision-making.

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 7-parameter tool with no annotations, the description covers parameter semantics and output format well, and an output schema exists for return values. Yet key operational context is missing: what the two fusion paths are, what OvisOCR2 verification means in practice, and how this 'main entry' relates to the specialized sibling tools.

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?

Every parameter is given additional meaning not present in the schema: types, defaults, 1-based indexing, and requiredness. This compensates strongly for the 0% schema description coverage. The main flaw is that the description marks fields as mandatory while the input schema does not list it as required, creating ambiguity about invocation validity.

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 frames the tool as a dual-channel fusion main entry and, through the Args/Returns sections, conveys that it extracts structured JSON from PDFs using field keys and page selections. However, it never explicitly says 'extract fields from a PDF' and does not distinguish itself from siblings like vision_extract or extract_table.

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 no guidance on when to use dual_extract versus vision_extract, parse_text, extract_table, or inspect_document. The only conditional language ('未指定/未启用 → 触发规则自行判定') concerns verify_pages defaults, not task-to-tool routing.

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. It does disclose the effects of render (PNG), tex (writes formulas.tex), sympy (validation), and the JSON return type. However, it does not state where rendered PNG files are written, whether files can be overwritten, or whether the operation is safe/non-destructive, leaving the behavioral picture incomplete.

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 well-structured with labeled Args and Returns sections, and each parameter is on a single scannable line. Some space is wasted on the redundant 'extract_formulas tool' header and the unexplained 'M5, T04' code, 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?

For a five-parameter extraction tool with no annotations, the description covers all input semantics and the return type, and an output schema is present so return details need not be expanded. It lacks usage routing and PNG file-destination details, but an agent has most of the information needed to invoke it 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 0%, but the Args section fully compensates: all five parameters receive a semantic explanation, type, default, and for pages a 1-based convention. This adds substantial meaning beyond the bare schema and leaves no parameter ambiguous.

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 the action '公式抽取' (formula extraction) and the output modes 'LaTeX + PNG', making the tool's function specific and distinct from siblings like extract_table and parse_text. It is not a mere tautology, though it never explicitly contrasts with a sibling and includes cryptic 'M5/T04' identifiers.

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 no guidance about when to choose extract_formulas over siblings such as vision_extract, dual_extract, or parse_text, and no exclusions or prerequisites beyond requiring pdf_path. The intended use case is only implied by the tool name and the phrase 公式抽取, not explicitly stated.

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 burden. It discloses cross-page merging, large-table layering, optional page-image rendering, and a structured JSON return. However, it leaves side effects ambiguous (e.g., whether csv/xlsx exports write files) and includes the unexplained 'M4，T04' tag.

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 Args/Returns layout is scannable and every parameter line provides useful semantics. The 'M4，T04' tag is unexplained and adds minor noise, but the structure remains efficient and readable.

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?

All parameters are documented, and an output schema exists, so the return-value shape is not a critical gap. The main missing context is explicit selection guidance relative to sibling tools and clarification of how non-JSON export formats are handled.

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%, and the description fully compensates by adding types, defaults, requiredness, 1-based page numbering, accepted format values, and rendering meaning for all five parameters. This is essential detail that goes well beyond the sparse input 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 names the operation as table extraction from a PDF and mentions cross-page merging and large-table layering, which adds useful specificity. It does not explicitly contrast the tool with siblings like parse_text or extract_formulas, but the intent 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 use for PDF table extraction, especially across pages or with large tables, but it never states when to prefer this tool over alternatives such as vision_extract, dual_extract, or extract_formulas. There are no explicit when-not-to-use conditions or alternative recommendations.

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 behavioral burden. It discloses that the tool probes two specific services and includes a note about async/sync implementation details. It does not explicitly state side-effect freedom or failure behavior, though an output schema exists and the operation is inherently read-only.

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 first sentence is concise, but the long '注意' section about FastMCP 1.29 handler internals and asyncio.run nesting is irrelevant to an agent selecting or invoking the tool. This implementation detail should be removed or moved to developer documentation; it does not earn its place in the tool description.

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 health probe with an output schema, the essential information is present: what is being probed (MinerU + Ollama) and that it is a liveness check. The async note is extraneous but not harmful, and the missing failure semantics are likely covered by the output schema.

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

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

The tool has zero parameters and the schema confirms 100% coverage with no required properties. Per the rubric, zero parameters receive a baseline of 4; no additional parameter documentation is 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 states 'MinerU + Ollama 双服务探活' (liveness probe for both MinerU and Ollama services), giving a specific verb and resource. It clearly distinguishes this tool from the seven extraction/processing siblings, so an agent can tell what it is for without inspecting 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 purpose implies when to use it (check service health), and the sibling tools are obviously unrelated, but there is no explicit guidance on when to call this versus alternatives. There are also no exclusions or prerequisites mentioned.

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 states that it returns structured JSON and implies it's a read operation, but it does not explicitly confirm that it's non-destructive, nor does it mention error handling, file validation, or any side effects. The internal references like 'M6, P1' and 'PRD §4.6' add noise without behavioral clarity.

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 front-loaded with the purpose, but it includes internal project codes like 'M6, P1' and 'PRD §4.6' that are irrelevant to an AI agent. The Args/Returns structure is clear, but the extraneous metadata detracts from cleanliness.

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 simplicity (one parameter) and the existence of an output schema, the description partially covers the return content but misses crucial usage guidance and behavioral details. It does not explain when to choose this tool over siblings, what happens on invalid input, or whether it is safe to call repeatedly. The absence of annotations makes these gaps more significant.

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 defines only pdf_path as a required string, and the description adds 'PDF 路径（必填）' which merely repeats that it's required. No additional meaning is provided about the path format, whether it's local or remote, or any constraints. Since schema description coverage is 0%, the description should compensate but fails to add substantive 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?

The description clearly states the tool's purpose: it inspects a PDF document and returns structured JSON containing pages, tables, images, formulas, and text characters. This is specific about the verb (inspect) and resource (PDF document), but it does not explicitly differentiate from siblings like parse_text or extract_table, so it doesn't fully distinguish itself.

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 guidance is given on when to use this tool versus alternatives. The description mentions '轻量' (lightweight), which could imply it's a quick overview, but it never states when to prefer it over parse_text, extract_table, or other siblings. There are no explicit usage conditions or exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects, permissions, rate limits, or how the tool interacts with the PDF. It only states that it returns structured JSON, which is minimal.

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 Args and Returns, but includes jargon like '信号②' and '触发规则自行判定' that are unclear to a general agent. It is not excessively long but could be tightened and made more accessible.

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

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

Given no annotations and no explicit purpose statement, the description is incomplete. It does not explain what happens on invalid pages, error handling, or how the output relates to the input. An agent cannot fully predict behavior from this alone.

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. It explains pdf_path as required, pages and verify_pages as int/list/None with 1-based indexing, and clarifies verify_pages is for OvisOCR2 validation. This adds meaning beyond the bare 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 'MinerU 文本路单跑' which is a vague pipeline reference rather than a clear statement of what the tool does. It mentions returning structured JSON but never explicitly says it extracts or parses text from a PDF, leaving the core action ambiguous for an agent.

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 no guidance on when to use parse_text versus siblings like vision_extract, dual_extract, extract_table, or extract_formulas. No conditions, exclusions, or alternative routing are mentioned, so an agent cannot determine the appropriate context.

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

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

With no annotations, the description carries the behavioral burden. It discloses that output_dir must be within the output root and that the return value is structured JSON with keys {ok, errors, manifest_ok}, which is helpful. However, it does not explicitly state that validation is non-destructive, what the validation actually checks, how errors are reported, or whether any manifest is required.

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 short and logically structured with a summary plus Args/Returns sections. It has almost no filler, though the opening repeats the tool name and the M6/C1 tag adds little without context.

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

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

For a single-parameter validation tool, the description covers purpose, the parameter, a key constraint, and the return shape. It is incomplete though: it does not say when to prefer this tool over siblings, what structural checks are performed, or the meaning of manifest_ok/errors beyond the key names. The presence of an output schema mitigates the return-format gap.

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 0%, so the description must explain the parameter, and it does: output_dir is the directory to validate, accepts absolute or relative paths, and must lie within the output root. This adds real meaning beyond the bare schema type, though 'output root' is not defined and no example value is given.

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 the tool performs output structure validation ('输出结构校验') and identifies the target resource as a directory to validate. It is sufficiently distinct from the sibling extraction/inspection tools, though it is expressed as a noun phrase rather than a clear verb+resource action and the M6/C1 shorthand is unexplained.

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 no guidance on when to use this tool versus siblings such as inspect_document or health. The description provides a path constraint but no exclusions, prerequisites, or alternative routing, so the agent must infer the tool's role from its name and context.

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

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

No annotations are present, so the description carries full burden for behavioral disclosure. It only mentions that pages is ignored for image input and that the return is structured JSON. It omits side effects, external model invocation, network/API usage, file format limitations, and error behavior, which are important for a vision-based extraction tool.

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 structured Arg/Returns layout is efficient and easy to scan. The version note about V1.3 image_path is slightly extraneous but not harmful; the summary phrase '视觉路单跑' is terse to the point of opacity.

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 parameter semantics and return type, which is adequate given an output schema exists. However, it does not explain the actual extraction behavior, supported input formats beyond PNG/JPG, or how this tool fits among the sibling extraction/parsing tools. For a 5-parameter tool with no annotations, this leaves meaning 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 Args section documents every parameter with types, constraints, and defaults (e.g., pdf_path vs image_path mutual exclusivity, fields being required, pages being 1-based/ignored for images, model defaulting to Settings.ollama_model). This fully compensates for the 0% schema description 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 first line '视觉路单跑' is a vague shorthand for visual waybill extraction rather than an explicit verb+resource statement. The Args/Returns sections imply an extraction task, and the tool name 'vision_extract' helps, but the description does not clearly define what the tool does or how it differs from siblings like extract_table or dual_extract.

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 input constraints ('pdf_path and image_path are mutually exclusive and one must be provided'; 'pages ignored for image input') but never states when to choose this tool over sibling extractors, nor any scenario-based guidance. It is limited to parameter mechanics, not use-case routing.

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