Better Design

Review an Illustration

review-illustration

Renders an SVG illustration in a browser and returns its visible faults against Better Design's illustration principles, such as open shapes, floating parts, inconsistent light and contents outside their container. Pass the SVG and what it is meant to show, and style "isometric" for a technical figure. Pass the returned reviewToken back to review the same drawing again. SVG that carries scripts, event handlers or remote references is refused.

Input Schema

TableJSON 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

TableJSON 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.

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / style

Added value: +{
+  "description": "Use \"isometric\" for a figure drawn with get-illustration-guide, so it is judged by those rules.",
+  "enum": [
+    "flat",
+    "isometric"
+  ],
+  "type": "string"
+}

First observedOct 4, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds behavior beyond annotations: unsafe SVGs (scripts, event handlers, remote references) are refused, and re-reviewing with a token is free, which the non-idempotent annotation alone wouldn't convey. The readOnlyHint=false profile is consistent with a rendering/validation operation, and it discloses the rejection policy rather than just the safety flags.

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?

Four compact sentences, front-loaded with what the tool does, then invocation advice, then the safety caveat. No filler, though the style guidance partially duplicates the schema's enum description.

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

Completeness4/5

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

With an output schema present the return shape needn't be explained, and the description covers inputs, the token reuse flow, and the refusal condition. Only the `animated` motion-check parameter is unaddressed, leaving a minor gap for a moderately complex tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all five parameters; the description mostly restates the intent and style semantics already in the schema. It does not explain the `animated` flag at all, so it adds little beyond the structured fields.

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 (renders) and resource (SVG illustration in a browser) and specifies the exact output (visible faults against illustration principles) with concrete examples of fault categories. An agent can distinguish it from get-illustration-guide (which supplies rules) without opening the schema.

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

Usage Guidelines4/5

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

Gives clear invocation context: pass the SVG plus intent, use style "isometric" for technical figures, and reuse reviewToken to re-review the same drawing. It doesn't explicitly name alternative siblings or state when not to use it, but the operator conditions are concrete.

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

All Better Design tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.