generate_design_spec

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 implies that DESIGN.md is written, and the schema's outputPath field describes path resolution and rejection rules, but the description itself does not disclose overwrite behavior, permission requirements, failure modes, or whether generation is purely local. The mention of deterministic 5-State matrices adds some behavioral context but not enough for a file-writing generator.

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 front-loaded with the main action and artifact, and every clause relates to what the specification contains. It is somewhat dense as a single long sentence, but it avoids filler and communicates the output scope efficiently.

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 five parameters, nested uiScreens objects, no annotations, no output schema, and only 40% schema description coverage. The description explains the generated document's contents but leaves major gaps around parameter usage, file-writing behavior, path semantics, template presets, and when this tool should be selected over sibling generators.

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

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

Schema description coverage is only 40%, so the description should compensate, but it does not explain the parameters. It lists generated content such as color tokens, typography scale, component hierarchy, and screen states, but says nothing about detail modes, templatePreset values, uiScreens structure, projectName, or how outputPath affects behavior beyond what the schema already documents.

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 and resource: generates a frontend UI/UX Design Specification as DESIGN.md. It also names the document's concrete contents, so an agent can distinguish it from PRD/SRS/ERD generators by resource. However, it does not explicitly compare itself with any sibling tool such as generate_full_blueprint or generate_prd.

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 says what is generated but gives no explicit guidance on when to use this tool versus generate_srs, generate_prd, generate_sdd, generate_full_blueprint, or audit_spec_completeness. It does not state prerequisites, exclusions, or which sibling to choose when the user needs a broader blueprint instead of a design spec.

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