Skip to main content
Glama
nmassi

glyphs-mcp

by nmassi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

smart_scale

Resize glyphs with automatic stem width compensation to preserve stroke weight. Adjust width, height, or weight proportionally, keeping consistent visual density across masters.

Instructions

Scale glyphs with automatic stem weight compensation.

RECIPE: For multi-glyph scaling tasks, call get_recipe("scale_proportions") first — it includes pre/post stem verification and visual comparison steps.

Unlike simple affine transforms which distort stem weights, this tool:

  1. Measures reference stems (H for UC, n for LC) before scaling

  2. Applies the width/height transform

  3. Uses GlyphsFilterOffsetCurve to compensate stem thickness changes

  4. Reports before/after stem measurements for verification

All values are scale factors where 1.0 = no change.

Args: width: Horizontal scale factor. 0.97 = 3% narrower, 1.1 = 10% wider height: Vertical scale factor. 1.15 = 15% taller, 0.9 = 10% shorter weight: Target stem weight factor. 1.0 = maintain original stem thickness after scaling (compensate). 0.9 = make stems 10% thinner. 1.1 = 10% thicker. proportional: If true, height follows width (uniform scale with compensation) glyph_names: List of glyph names to process (empty = all exporting glyphs) master_id: Process only this master (empty = all masters) backup: Create backup layers before modifying (default true)

Examples: Condense 3% keeping weight: smart_scale(width=0.97, weight=1.0) Increase x-height 15% keeping weight: smart_scale(height=1.15, weight=1.0) Scale uniformly 90% with weight compensation: smart_scale(width=0.9, proportional=True) Make all stems 10% thicker: smart_scale(weight=1.1) Condense UC only: smart_scale(width=0.95, glyph_names=["A","B","C",...])

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
widthNo
backupNo
heightNo
weightNo
master_idNo
glyph_namesNo
proportionalNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it explains that the tool measures reference stems, applies transforms, compensates via GlyphsFilterOffsetCurve, reports before/after stem measurements, and creates backup layers by default. This makes side effects and safety behavior clear.

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

Conciseness5/5

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

The description is long but well-structured with a purpose statement, a RECIPE directive, a numbered algorithm, a complete parameter list, and usage examples. It avoids filler and every section adds information an agent needs to invoke the tool correctly.

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?

Given the absence of an output schema and annotations, the description is unusually complete: it covers all parameters, default behavior, backup safety, and algorithmic side effects. The only notable missing detail is the exact shape/format of the before/after stem measurement report, but the tool is still safely invocable without it.

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 description coverage is 0%, so the description must explain all parameters, and it does: width, height, weight, proportional, glyph_names, master_id, and backup all receive concrete meanings and examples. The examples clarify scale-factor semantics like 0.97 = 3% narrower and weight=1.0 = maintain stem thickness.

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?

The description states a specific verb and resource: 'Scale glyphs with automatic stem weight compensation.' It further differentiates itself from 'simple affine transforms which distort stem weights,' so an agent can distinguish this from plain scaling operations without reading the schema.

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?

The description explicitly recommends calling get_recipe('scale_proportions') first for multi-glyph scaling tasks, and it contrasts the tool with simple affine transforms. However, it does not name sibling tools like rmx_scale or explicitly state when those should be preferred over smart_scale.

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

Deploy Server

Other Tools