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

No annotations exist, so the description carries the full behavioral burden. It names the accepted file formats, which is useful, but says nothing about required file existence/permissions, size limits, failure behavior, or what the extraction produces.

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?

A single compact clause with the action front-loaded and the format list appended. No filler, though it is arguably too terse given the missing behavioral detail.

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

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

With no output schema and no annotations, the description should describe the return shape (e.g. structured design requirements vs raw text) and error conditions. It covers the input formats but leaves the output and failure modes entirely unspecified.

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% for the single filePath parameter, so the baseline is 3. The description adds supported formats, which is mildly relevant to what filePath may point at, but no path syntax or constraint 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?

States a specific verb (解析/提取) and resource (需求文档), plus the accepted formats (Word/PDF/MD). An agent can grasp the tool's job without opening the schema, though it does not name or contrast the sibling tools it sits alongside.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as generate_design or extract_tokens. The role as an input-parsing step is only implied by the description text.

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 of behavioral disclosure. It mentions multi-image support, but says nothing about whether the audit is read-only, what it returns, how the diff/threshold behavior surfaces, or any auth/side-effect characteristics. For an audit tool with zero annotation coverage this is a notable gap.

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?

A single short sentence with the core action front-loaded and no filler. Efficient, though the dash-separated trailing clause is brief enough that it could have carried more useful context instead.

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 nested options object, 3 parameters, and no output schema, yet the description never explains what the audit produces or how results are reported. With no annotations and no output schema, the description should do much more to be 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 67%, so most parameters are documented in the schema itself. The description adds only the 'multi reference image' hint, which loosely maps to referenceImagePaths being an array, but gives no meaning for designCode or the nested options. 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?

States a specific verb (对比/审计 = compare/audit) and resource (generated code vs reference images), so the core action is clear. It does not explicitly distinguish itself from siblings like generate_design or extract_tokens, so it falls short of a 5.

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

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

The phrase '对比生成的代码与参考图' implies the usage context (you have generated code and reference images to validate), but there is no explicit when-to-use, when-not-to-use, or reference to alternatives among the sibling tools. Usage is only implied.

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

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

No annotations are provided, so the description carries the full burden. It discloses batch/multi-image support, which is useful context, but says nothing about caching behavior (which the schema exposes), concurrency limits, permissions, failure modes on unreadable images, or what the extraction returns. For an unannotated tool with a nested options object, this is a significant gap.

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?

A single compact sentence with the core verb-resource pairing front-loaded and the batch capability trailing as a qualifier. No wasted clauses, though it is thin rather than lean — brevity here partly reflects under-specification.

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 annotations, no output schema, a nested options object, and only 50% schema coverage, the description should do more work. It never explains the shape of the extracted tokens, how caching or concurrency affect results, or how multi-image output is aggregated — all things an agent needs before invoking.

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%, so the schema already documents imagePaths and the five nested options fields (useCache, extractColors, extractSpacing, extractTypography, maxConcurrency) with defaults. The description's mention of 颜色/间距/圆角 loosely maps to the extraction flags but adds no syntax, format, or default information beyond the 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?

States a specific verb (提取/extract) and resource (Design Tokens) with concrete examples of what tokens are covered (颜色、间距、圆角) and the source (参考设计图). It goes beyond a tautology of the name. It does not, however, distinguish itself from siblings like analyze_requirement or audit_visual, which also operate on design inputs.

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 statement of when to use this tool versus analyze_requirement, generate_design, or audit_visual, and no prerequisites or exclusions are given. The 'batch processing' note describes a capability, not a usage condition. The agent must infer the routing from the name alone.

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 not say whether generating writes or overwrites a file at outputPath, what the default output behavior is, how long generation takes, or what the result contains. For a generation/write operation with zero annotation coverage this is a meaningful gap.

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?

A single front-loaded sentence with no filler or repetition. It is efficiently structured, though the extreme brevity is partly a symptom of missing content rather than disciplined compression.

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?

Minimum viable for a 3-parameter generator whose schema is fully documented and which has no output schema. However, with nested object inputs, a file-writing outputPath, and sibling tools in a pipeline, the description leaves the agent guessing about ordering, side effects, and result shape.

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 all three parameters including nested objects are already documented in the schema. The description names the two main inputs but adds no format, shape, or constraint detail beyond what the schema supplies, so the baseline of 3 applies.

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

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

The description names a concrete verb (生成/generate) and resource (HTML/Tailwind 设计稿), plus the two inputs it consumes (需求 and Design Tokens). It is clear what the tool produces, but it does not differentiate itself from siblings such as analyze_requirement or extract_tokens, which it actually depends on.

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 statement of when to use this tool versus the other three siblings, no prerequisite ordering (e.g. must run analyze_requirement and extract_tokens first), and no note on whether it supersedes or follows audit_visual. The '来自 extract_tokens' hints at an upstream dependency in the schema but the description itself gives no workflow guidance.

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