Designers

Vertical rhythm

vertical_rhythm

Read-only

Snap a type scale to a baseline grid. Pass baseline (px, default 8) and sizes: an array of pixel sizes, or "name:size" strings such as "h1:48" and "body:16". Optional: bodySize (default 16) and rootPx (default 16). Returns, per size, a line-height rounded to a whole number of baseline units (never under 1.1 times the size), margin-block start and end in baseline multiples, and CSS using calc(var(--baseline) * n). Preferred ratios fall as size rises (1.5 up to 18px, 1.35 up to 28px, 1.25 up to 40px, then 1.15); that curve and the margin pattern are conventions, with body leading in line with UXPin's 1.4 to 1.6 and vertical rhythm as a composition aid per Smashing's Typography Best Practices. Aligns line boxes and margins; it does not read font metrics.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sizes": "<sizes>"
    },
    "name": "vertical_rhythm"
  }
}

Input Schema

Name	Required	Description
`sizes`	Yes	Font sizes in px, or "name:size" strings, up to 30.
`rootPx`	No	Root font size for rem output (default 16).
`baseline`	No	Baseline unit in px (2 to 48, default 8).
`bodySize`	No	Body font size in px (default 16).

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 24, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds valuable behavioral context by specifying return values (line-height, margin-block, CSS) and clarifying that it does not read font metrics, preventing misuse.

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 purpose is front-loaded in the first sentence, and every subsequent sentence earns its place by describing parameters, returns, conventions, and limitations. It is slightly dense and could benefit from bullet points, but not verbose.

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?

Given no output schema and comprehensive parameter descriptions, the description is complete: it explains the return format, the conventions used, and the key limitation (no font metrics reading). An agent has everything needed to invoke it correctly.

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 baseline is 3. The description repeats defaults and adds a concrete example ('h1:48'), but does not contribute significant meaning beyond what the schema already documents.

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 ('Snap') and resource ('type scale to a baseline grid'), and the detailed output description distinguishes it from siblings like audit_type_scale or modular_scale. An agent can immediately tell this tool generates baseline-aligned typography metrics rather than auditing or generating scales.

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?

Provides clear context by framing it as a 'composition aid' and citing UXPin and Smashing conventions, but stops short of explicitly naming alternatives or stating when not to use it (e.g., for auditing existing scales).

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

All Designers tools Inspect

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

Need Help?