Skip to main content
Glama

Proportion calculator

calculate_proportion
Read-only

Work out proportions. Pass ratio (golden, root2 or a-series, root3, any a:b such as 3:2 or 16:9, or a decimal such as 1.414; default golden) and width or height. Optionally orientation (landscape by default, or portrait) and container (length to split; defaults to the long side). Returns the missing side, the split of the container into a major and minor part at that ratio (with CSS fr and px forms), a table of heights at the same width for ten common ratios, and, when you give both width and height as a source image, centered crop sizes and offsets for the target ratio and common alternatives with the share of area kept. Root-2 is the ISO A-series ratio, where folding a sheet in half keeps its shape. Sources: Graphic Design Solutions (golden section); Samara, Making and Breaking the Grid; Müller-Brockmann, Grid Systems in Graphic Design. That any one ratio is more beautiful is a convention, not a finding. 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": "calculate_proportion"
  }
}

Input Schema

NameRequiredDescriptionDefault
ratioNogolden, root2, a-series, 3:2, 16:9, 4:5, a decimal like 1.414, or any a:b. Default golden.
widthNoKnown width in px (or any unit).
heightNoKnown height. Give one of width or height; give both to get crop suggestions.
containerNoLength to split into major and minor parts.
orientationNoLandscape (default) makes the width the long side.

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 declare readOnly, non-destructive and closed-world, so the safety profile is covered. The description adds defaults ('golden', landscape, container falls back to the long side) and states 'Pure arithmetic, nothing stored', which is useful confirming context. It does not describe precision/rounding or unit behavior in the returned values.

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?

Inputs and outputs are front-loaded, which is good, but the second sentence is a very long run-on stacking four output types. The trailing source citations and the 'beauty is a convention' caveat are interesting but not needed to invoke the tool correctly, so it is larger than the task requires.

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?

There is no output schema, so the description must carry the return contract, and it does: missing side, major/minor split with CSS fr and px forms, a ten-ratio height table, and crop sizes/offsets with area-kept share. An agent can anticipate the response shape and choose inputs accordingly.

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 100%, so baseline is 3, but the description adds real meaning: the accepted ratio spellings (golden, root2, a-series, any a:b, decimal), that container defaults to the long side (not in the schema), and the effect of passing both width and height. That goes beyond the schema's own text.

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 and resource ('work out proportions') and immediately enumerates the concrete outputs: missing side, container split, ratio height table, and crop offsets. This clearly differentiates it from nearby siblings such as convert_paper_size or modular_scale, which handle unit conversion and scale generation rather than ratio arithmetic and cropping.

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?

Explains the two input modes: give one of width/height to get the missing side, give both to get crop suggestions. That is actionable context. It does not explicitly name an alternative tool or say when not to use it, so it stops short of the top band.

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