Skip to main content
Glama
Sign In

Designers

by com.allthepossibles
OverviewDiscussionsAdmin

Proximity and alignment check

check_proximity_alignment
Read-only

Find layout slips that read as mistakes. Pass boxes (array or JSON string of {x, y, w, h, label}, 2 to 400 boxes) or html plus optional css. For markup, geometry comes from data-x, data-y, data-w, data-h attributes or from left, top, width and height in px (inline style, or simple .class, #id and tag rules in css); elements without all four are skipped and counted. Nothing is rendered, so this reads declared numbers only. Reports (1) near-misses: left, right, top, bottom or center lines of two boxes that differ by more than 0.01px and no more than tolerance (default 6px), with both values and the difference; (2) inconsistent gaps between three or more siblings that share a row or column, listing every gap and the most common one; (3) orphans, boxes that line up with nothing and sit more than twice the median nearest-neighbor distance away. Sources: Müller-Brockmann, Grid Systems in Graphic Design (alignment to a shared structure); Lupton, Thinking with Type (alignment and grouping); Wroblewski, Web Form Design (labels close to their fields). The tolerance and orphan thresholds are conventions. Pure arithmetic, nothing stored.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_proximity_alignment"
  }
}

Input Schema

NameRequiredDescriptionDefault
cssNoCSS for the markup (simple class, id and tag selectors).
htmlNoMarkup with positioned elements (alternative to boxes).
boxesNoBoxes as {x, y, w, h, label}. A JSON string is also accepted.
toleranceNoNear-miss window in px (default 6, max 50).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover safety, yet the description still adds substantive behavior: nothing is rendered so only declared numbers are read, elements missing any of the four geometry values are skipped and counted, box count is bounded at 2–400, and the thresholds are explicitly labeled conventions rather than truths. This is exactly the extra context annotations cannot carry.

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?

Dense and front-loaded: the input options come first, then the geometry rules, then the three report types. The literature citation sentence is the one piece of filler, though it does justify why the tolerance and orphan rules are conventions.

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?

No output schema exists, and the description compensates by spelling out the fields of each report (both values plus the difference, every gap plus the most common one, orphan threshold logic). Combined with input-source rules and skip behavior, an agent has enough to call it and interpret results correctly.

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 earns above that by explaining where geometry comes from (data-x/y/w/h attributes, px in inline style, or simple .class/#id/tag rules in css) and what happens when a value is absent. It does not clarify what `label` is used for in the reported output.

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?

Opens with a concrete verb and target ('Find layout slips that read as mistakes') and then enumerates the three defect classes it reports: near-misses, inconsistent gaps, and orphans. An agent can tell precisely what this produces versus a generic spacing audit.

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

Usage Guidelines3/5

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

The input contract is explained well (boxes OR html+css), which implies usage, but the description never states when to prefer this over neighbouring tools such as audit_spacing or vertical_rhythm. Given ~150 siblings in the same domain, the absence of any routing guidance is a real gap.

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

All Designers toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources