Skip to main content
Glama

Kalpana Designer

Measure text

measure_text
Read-onlyIdempotent

Measure text as the renderer lays it out: each line and its width, the height, and whether the last line is a widow; or, with width and fit_height, the largest font size that fits that box. With page_id and layer_id it measures that text layer as styled. texts measures many at once, and pack lays them out as chips in rows and returns each chip's box. Read-only; it changes nothing. Use it before placing or sizing text instead of guessing; for text already overflowing in a design use check_layout.

Input Schema

NameRequiredDescriptionDefault
packNoWith `texts`: lay them out as pills or chips packed in rows with no overlaps, and return each one's box (x, y, width, height) ready for create_layers.
runsNoText in differently styled runs, as create_layers takes them (mixed families or weights), in place of `text`.
textNoThe text to measure (or give `texts`).
wrapNoLine breaks as create_layers `wrap` sets them: "normal", "balance" or "pretty" (a stored layer keeps its own unless given).
textsNoMeasure many texts in one call (same font, size and width); the result lists each one's width, height and lines.
widthNoWrap within this width (px); one line when omitted.
intentNoOptional: a few words on why.
page_idNoThe page to work on, as returned by create_design.
layer_idNo
max_sizeNo
min_sizeNo
font_sizeNoMeasure at this size (px).
fit_heightNoInstead of measuring, find the largest size in [min_size, max_size] whose text fits `width` x `fit_height`.
font_styleNo"Regular", "Bold"...
font_familyNo
line_heightNoline_height like create_layers ("120%", "auto", or px).
letter_spacingNoletter_spacing like create_layers: px number or a percentage of the font size like "-3%".
min_last_line_wordsNoFewest words a wrapped paragraph may end on, as create_layers takes it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: measurement follows renderer layout, reports line widths/height/widow status, can search for the largest fitting font size, treats page/layer text as styled, and returns chip boxes for `pack`.

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 description is front-loaded with the core measurement purpose and then adds modes and alternatives efficiently. It is dense but nearly every clause carries useful routing or behavior information; the read-only reminder is slightly redundant with annotations but reinforces safety.

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 complex 18-parameter, nested-schema tool with no output schema, the description explains the main operational modes and enough about returned values (line widths, height, widow status, chip boxes) to call it correctly. Remaining gaps around some styling parameters are largely covered by the schema.

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 78%, so many parameters are already documented structurally. The description adds meaningful mode semantics for central parameters, especially `width` with `fit_height`, `texts`, `pack`, `page_id`/`layer_id`, and `runs`, though it does not explain every lower-level styling parameter.

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 uses the specific verb 'measure' with the resource 'text' and clearly distinguishes its modes: line measurement, fit-to-box sizing, styled-layer measurement, batch `texts`, and chip `pack` layout. It also explicitly contrasts itself with `check_layout` for overflowing existing text.

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

Usage Guidelines5/5

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

It gives direct guidance to use the tool before placing or sizing text instead of guessing, and names `check_layout` as the alternative for text already overflowing in a design. The mode-selection conditions for `width`/`fit_height`, `texts`, and `pack` are also stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources