Designers

Modular type scale

modular_scale

Read-only

Build a modular type scale. Pass base (px, default 16) and ratio (a number from 1.01 to 4, or a name: minor second, major second, minor third, major third, perfect fourth, augmented fourth, perfect fifth, golden, major sixth, octave; default major third 1.25). Optional: stepsUp (default 6), stepsDown (default 2), rootPx (default 16), minViewport and maxViewport (defaults 320 and 1280), minBase and minRatio for the small-screen end of the fluid scale (default: same base, ratio pulled 20 percent toward 1). Returns each step with px, rem and a clamp() expression that interpolates linearly between the two viewports, plus fixed and fluid CSS custom properties. The ratio names come from music intervals and are a web design convention, not a law; Bringhurst, The Elements of Typographic Style, discusses scales of related sizes. Pure calculation, nothing is 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": "modular_scale"
  }
}

Input Schema

Name	Required	Description
`base`	No	Body size in px (8 to 64, default 16).
`ratio`	No	A number (1.01 to 4) or a name such as "major third", "perfect fourth", "golden". Default major third.
`rootPx`	No	Root font size for rem conversion (default 16).
`minBase`	No	Base size at the small viewport (default same as base).
`stepsUp`	No	Steps above the base (0 to 12, default 6).
`minRatio`	No	Ratio at the small viewport, number or name (default: 20 percent closer to 1 than ratio).
`stepsDown`	No	Steps below the base (0 to 6, default 2).
`maxViewport`	No	Viewport width in px where the fluid scale reaches full size (default 1280).
`minViewport`	No	Viewport width in px where the fluid scale uses its small values (default 320).

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 24, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'Pure calculation, nothing is stored.' It goes further by describing exactly what comes back — px, rem, clamp() expressions, and fixed vs fluid CSS custom properties — which matters because there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the core verb and inputs, but it is one dense paragraph where parameter details run together. The aside about music intervals and the Bringhurst citation does not help an agent decide or invoke, so it dilutes an otherwise efficient spec.

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?

For a 9-parameter, no-output-schema tool, the description covers defaults, the fluid two-viewport model, and the return shape, which is close to what an agent needs. Only sibling disambiguation is missing, and that is scored under usage guidelines rather than blocking correct invocation.

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 already 100%, so the baseline is 3, but the description adds real meaning: it enumerates the full set of ratio names, explains the fluid-interpolation interval (minViewport to maxViewport), and clarifies that minRatio defaults to the ratio pulled 20 percent toward 1. This goes beyond the terse schema strings.

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 specific verb and resource ('Build a modular type scale') and immediately names the two driving inputs, base and ratio. It is clearly distinguishable from siblings like audit_type_scale (an audit) and build_spacing_scale (a different scale family).

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 description implies when the tool applies — you want generated scale values with fluid clamp() output — and states 'Pure calculation, nothing is stored.' However, it never names alternatives (audit_type_scale, vertical_rhythm, build_spacing_scale) or says when not to reach for it, leaving the agent to infer selection.

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?