Better Design

Review an Illustration

review-illustration

Checks an SVG illustration in a real browser against project principles, names visible faults such as unclosed shapes, floating parts, conflicting light, and clipped contents before handoff.

Instructions

Look at an SVG illustration you drew and get back what is visibly wrong with it.

You write SVG blind. This renders it in a real browser and judges it against this project's illustration principles, so you find out that a shape does not close, a part floats unattached, the light comes from two directions, or contents sit outside the container meant to hold them.

Use it whenever you have drawn an illustration, before you hand it to anyone. Drawing something worth shipping usually takes 2 or 3 rounds.

How to call it:

Get the rules first with get-ui-principle({ topic: "svg-illustration" }) and draw against them. For an isometric technical figure, use get-illustration-guide and pass style: "isometric".
review-illustration({ svg, intent: "an open inbox tray with letters" }). Say what the drawing is meant to be, in your own words.
Fix what faults names, then call again passing reviewToken back. Reviewing the same drawing again costs nothing while that token is valid.
Stop when faults is empty.

Markup carrying script, event handlers, remote references, or styles that reach outside the drawing is refused rather than cleaned, so the drawing you fix is the drawing you sent.

Input Schema

Name	Required	Description
`svg`	Yes	The complete svg element you drew.
`style`	No	Use "isometric" for a figure drawn with get-illustration-guide, so it is judged by those rules.
`intent`	Yes	What it is meant to be, in plain words. For example "an open inbox tray with letters".
`animated`	No	Set when the drawing was meant to move, so the motion checks apply.
`reviewToken`	No	The token from a previous review of this drawing. Reviews it again free.

Output Schema

Name	Required	Description	Default
`faults`	Yes
`layers`	Yes
`unseen`	Yes
`message`	Yes
`reviewed`	Yes
`reviewToken`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that the SVG is rendered in a real browser and judged against project principles, that typical convergence takes 2-3 rounds, that re-reviewing with `reviewToken` is free, and that markup with script, event handlers, remote references, or out-of-scope styles is refused rather than sanitized. The annotations only flag non-readonly/non-destructive/non-idempotent, so this cost and rejection model is genuinely additive and does not contradict them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then a numbered 4-step call recipe that maps to the parameters and the stopping condition. Slightly long and the security sentence is arguably a second thought, but nearly every sentence carries actionable information for an agent that cannot see its own output.

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

Completeness5/5

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

An output schema exists and the description correctly references the `faults` field rather than re-documenting the return shape. Combined with the prerequisites, cost model, refusal policy, and stop condition, an agent has everything needed to call this correctly on the first attempt and to iterate.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top by explaining that `intent` should be phrased in the agent's own words, that `reviewToken` from a prior review makes the next pass free, and that `style: "isometric"` routes to the illustration-guide rule set. `animated` is only covered by the schema, which keeps this from a 5.

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

Purpose5/5

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

States a specific verb and resource ('Look at an SVG illustration you drew and get back what is visibly wrong with it') and enumerates the concrete fault classes it detects. It is clearly distinguished from siblings like get-ui-principle, get-illustration-guide, check-comprehension, and review-ui-code, and the opening line names the agent's actual situation ('You write SVG blind').

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

Usage Guidelines5/5

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

Explicitly says when to use it ('whenever you have drawn an illustration, before you hand it to anyone'), names the prerequisite sibling calls with the exact argument (`get-ui-principle({ topic: "svg-illustration" })`, `get-illustration-guide` with `style: "isometric"`), and gives a termination condition ('Stop when faults is empty'). No inference required.

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

Deploy Server