validate_user_journey

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

With no annotations at all, the description carries the full burden, yet it never states whether this is a read-only analysis or whether it mutates the document, nor what permissions/context it needs. It does disclose the specific findings it surfaces (orphan screens, dead-end traps, unprotected destructive actions), which is genuinely useful, but the operational profile is absent.

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; the key scope (canvas artboards) and the three defect categories are packed efficiently. The trailing clause 'without confirmation safeguards' is slightly redundant with 'unprotected destructive actions' but not costly.

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-param tool with no output schema, the description should ideally indicate what the result looks like and whether the scan covers the whole document or the current selection; it partly compensates by listing the defect types it reports. No annotations means the safety/operational picture is missing, leaving a real 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?

The tool takes zero parameters, so the schema is trivially complete and the baseline of 4 applies. Nothing about arguments needs explaining.

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 gives a specific verb (verify) and a precise resource (user journey continuum and prototype interaction completeness), then enumerates the exact defect classes it looks for. It is clearly distinguishable from siblings like audit_ux_heuristics or lint_design_compliance, though it never explicitly names them.

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 run this versus adjacent tools (audit_ux_heuristics, get_prototype_connections, lint_design_compliance), nor any prerequisite or scope guidance. Usage must be inferred from the design-review context alone.

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