Skip to main content
Glama
Sign In

Designers

by com.allthepossibles
OverviewDiscussionsAdmin

Spacing scale

build_spacing_scale
Read-only

Generate spacing tokens from a base unit. Pass base (px, default 8) and one of: nothing (linear 4/8-point ladder: half step, 1x, 1.5x, 2x, 3x, 4x, 5x, 6x, 8x ...), ratio (modular: base times ratio to the power n, starting at the base), or steps (your own list of px values). count sets the token count (default 10, max 18 for linear and 24 for modular). Each token returns px, rem at 16px, a usage line (hairline gap, inside a component, component padding, between siblings, between groups, between sections), and a flag when the value is not a whole multiple of the base or is a fractional pixel. Also returns CSS custom properties in rem and in px, with an optional prefix (default space). Sources: Samara, Making and Breaking the Grid (consistent units); Graver and Jura, Best Practices for Graphic Designers (modular scales). The 4 or 8 point unit itself is a convention. 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": "build_spacing_scale"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseNoBase unit in px (default 8).
countNoHow many tokens (default 10).
ratioNoModular ratio, for example 1.5 or 1.25. Omit for a linear scale.
stepsNoYour own step list in px, for example [4, 8, 12, 16, 24, 40].
prefixNoCustom property prefix (default space).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description reinforces this with 'Pure arithmetic, nothing stored.' It also discloses the per-token payload (px, rem, usage line, non-multiple flag) and the CSS custom property output with a `prefix` default, which is behavior beyond the annotations.

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?

The core action is front-loaded in the first clause and every sentence carries density rather than filler. It is a long, clause-heavy paragraph, and the citation of Samara/Graver/Jura is arguably padding for an agent deciding how to call it.

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?

With no output schema, the description fully compensates by describing the returned token structure, the CSS custom property output, and the anomaly flag. Mode selection, defaults, and caps are all covered, leaving nothing an agent needs in order to call it correctly.

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%, yet the description still adds meaning the schema lacks: the maximum token counts differ by mode (18 linear vs 24 modular), `steps` overrides `ratio`, and `count`/`prefix` defaults are tied to concrete behavior. This is meaningful enrichment on top of a fully documented schema.

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

Purpose4/5

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

States a specific verb and resource ('Generate spacing tokens from a base unit') and enumerates the three generation modes, so an agent knows exactly what the tool produces. It does not, however, distinguish itself from the sibling `modular_scale` or `audit_token_scales`, which an agent could reasonably confuse with the ratio/modular path described here.

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?

Explicitly explains the three mutually exclusive usage modes ('one of: nothing ... `ratio` ... or `steps`') with per-mode defaults and caps, which is strong when-to-use guidance. It stops short of exclusions or naming an alternative tool when a full scale already exists (e.g. `audit_token_scales`).

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