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 the tool is 'deterministic', describes the two passes (rulebook and optional theme conformance), and lists the output (score, verdict, fix list). It does not mention side effects (e.g., whether source is stored or modified), but as a read-only critique tool the lack of side effects is implied. The conditional theme pass is clearly explained.

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 dense but well-structured, with a purpose statement, a detailed rulebook list, an output summary, and usage guidance in only two sentences. Every clause adds useful information, though the parenthetical list makes it a bit heavy. It earns a 4 for being concise yet comprehensive.

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 fully covers the tool's purpose, inputs, behavioral details, return value, and usage threshold. It even names an alternative for a different use case. The only minor omissions are an explicit explanation of the 'ship verdict' contents and whether any setup or prerequisites are needed, but these are not essential for an agent to select and invoke the tool 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 100% (3/3 params documented), so the baseline is 3. The description adds context about the theme parameter ('when a Standout app theme is installed') and specifies source as React/JSX/HTML, but it does not meaningfully augment the already-clear schema descriptions. No additional parameter syntax or constraints are provided.

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 'Deterministic critique for APPLICATION UI' and enumerates specific slop patterns (radius chaos, card-in-card, gray-on-gray text) that the rulebook checks. It further distinguishes itself from critique_design by explicitly targeting application UIs versus marketing pages, making the tool's purpose unmistakable and differentiated from siblings.

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?

Explicitly instructs 'Use after building every view; re-run until the score clears 85.' It also directs the agent to use critique_design for marketing/landing pages, providing a clear alternative. This is a textbook example of when-to-use and 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.