Better Design

Inspect Rendered Spacing

inspect-spacing

Read-onlyIdempotent

Measure rendered UI spacing and return an inline report with a clear problem and correction, so you can verify layout after UI changes.

Instructions

Measure spacing in a rendered interface. Returns an inline report with a clear problem and correction, plus a short text summary. Full measurements remain available in the report and structuredContent. Use after UI changes when a browser or DOM evaluator is available. A Shopify theme preview or a React Native web export counts: run the script in that page. A native app on an iOS simulator (SwiftUI, or React Native) is measured from its accessibility tree instead: run axe describe-ui --udid <simulator id> (AXe: brew install cameroncooke/axe/axe; point DEVELOPER_DIR at Xcode if it asks) on each screen and pass the printed JSON as nativeStates. That needs no capture script and no widths.

This is the runtime counterpart to get-review-rules. It automatically loads the live visual-design rubric, but it does not guess pixel values from a screenshot. Exact claims come from DOM geometry.

It measures geometry only. A score of 100 is not visual approval: it cannot judge hierarchy or whether the design works, so look at a screenshot before you call a screen done.

Workflow:

Call with no states to receive a read-only browser capture script in structuredContent.captureScript. Use detail: "full" if your client reads only text; it includes the script in text. That call measures nothing.
Evaluate that script in each rendered state you need to review: at minimum 1440, 1728 and 390 wide. Also capture named hover, focus, selected, and open states when they change a control's surface or layout.
Call again with the captured states and the project's spacing scale when known. The layout counts as measured only when this second call returns status completed; reading the snapshot yourself is not a measurement. The report and summary start with the highest-priority correction. Read structuredContent.findings or use detail: "full" for every returned finding, measurement, and fix. Structured evidence retains captured geometry and optional screenshots for report renderers.
At desktop widths it also checks five layout roles (sidebar width, page inset, section gap, column gap, card padding) against one density: the density argument, else the density the page's kit declares, else the closest measured mode. structuredContent.density names the mode, where it came from, and each role's measured and expected value.

The capture reads visible layout geometry, computed spacing, corner radii, surface styles, the number of line boxes each text block rendered, short accessible labels for interactive controls, the text of headings, the alt text of images, and the page title. It does not collect source code, cookies, form values, or network data. Add data-bd-inspect-label, data-bd-symmetry, data-bd-group, data-bd-compare-size, data-bd-align-group, and data-bd-align-edge attributes when the intended relationship cannot be inferred safely.

Input Schema

Name	Required	Description	Default
`detail`	No	Defaults to a short summary alongside the inline report. Use full for the capture script or all findings and measurements in text-only clients.	summary
`states`	No	Rendered layout states from the capture script. Omit on the first call to receive the script.
`context`	No	Optional. One sentence on WHY you are calling this and what the user asked for (e.g. 'adding nav icons for the fintech dashboard'). Used only for usage analytics; does not change the result.
`density`	No	The layout density to check against: compact, comfortable or spacious. Omit it to use the project's design config, then the design system's default, both read from the page's --layout-density variable, then the mode closest to the measured page.
`tolerance`	No	Pixel tolerance for grouping measurements. Defaults to 1px.
`nativeStates`	No	Native screens: a name for each, and the JSON `axe describe-ui` printed for it. Frames are in points and are measured as pixels.
`spacingScale`	No	Project spacing tokens in CSS pixels. Defaults to 4, 8, 12, 16, 24, 32, 48, 64, 96, 128.

Output Schema

Name	Required	Description	Default
`score`	No
`rubric`	No
`states`	No
`status`	Yes
`density`	No
`summary`	No
`findings`	No
`nextStep`	No
`rubricStatus`	No
`captureScript`	No
`missingWidths`	No
`capturedWidths`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, and the description adds substantial context beyond them: the first call measures nothing, the layout only counts as measured on status `completed`, a score of 100 is not visual approval, exactly what data is and isn't collected, and the data-bd-* attributes needed for ambiguous relationships. Rich and non-contradictory.

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 purpose and return value, then organized into a numbered workflow and a data-scope paragraph. It is long, but nearly every line carries procedural information an agent needs; the density/states explanations are the only mildly verbose stretches.

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?

For a complex multi-call measurement tool with an output schema and dense nested input schema, the description supplies the missing procedural glue (two-call flow, success criterion, capture scope, native path). Nothing an agent needs to invoke it correctly is absent.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds real semantics: `detail` full for text-only clients, `states` omitted on the first call to fetch the capture script, the `density` fallback chain (argument → kit → measured mode), and `nativeStates` fed from `axe describe-ui` output. This goes well beyond the schema.

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 (measure spacing in a rendered interface) and immediately distinguishes itself as the runtime counterpart to get-review-rules, explicitly contrasting DOM geometry with screenshot guessing. The agent can tell what it does and how it differs from siblings.

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?

Provides an explicit four-step workflow, names the exact viewport widths to test, tells the agent when a browser vs. native simulator path applies, and states the measured-only-on-second-call condition. No alternatives are left to inference.

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

Deploy Server