Skip to main content
Glama

Build a printed surface

compose_surface

Make a flat surface that looks PRINTED ON a real material: a quote on a stretched canvas, a poster, a shop sign, a label, a plaque, a book cover. Start from a base: a texture set from the library (setId from list_assets; tiled at tileSize meters, or mode "stretch" for a whole-sheet scan), explicit maps {baseColor, normal, ormh} urls, or a flat color; tint re-colours the base and keeps its detail. Then layers, painted in order: text {text (use \n or | for line breaks), font typewriter|sans|horror, weight, size (letter height in meters), color, align, x/y (the block centre, 0..1 from left/top), maxWidth (share of the width; the size shrinks to fit), tooth (0..1, how much ink skips the low spots of the weave), dry (patchy ribbon), jitter (typewriter wobble)}; image {src (an /assets url), x, y, width (share of the surface width), opacity, blend normal|multiply}; stains {amount, color, scale, seed}; spatter {x, y, size, drips, color (blood by default), seed}; grime {edge}; fill {color, opacity}. Ink and spatter sink into the base relief, emboss its normal and read glossier than the base, so light rakes across it like the real thing. output "panel" (default) saves a thin box MODEL of width x height x depth meters, its face looking down +X like the library picture frames, with a phone-sized copy made automatically, and a model waits for its room so a many-room site stays light on phones; place it with the place op the result gives. output "material" saves a baseColor/normal/ormh set and returns materialMaps for apply_ops (it stretches once across a face, repeat 1). To fill a picture frame, measure the frame first (measure gives its opening) and make the panel about 0.2 m larger than the opening both ways, placed just behind the frame's front. Returns a small preview image of the surface.

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": {
      "width": "<width>",
      "height": "<height>"
    },
    "name": "compose_surface"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseNoThe material the surface is made of.
depthNoPanel thickness in meters (default 0.03).
labelNo
widthYesSurface width in meters.
heightYesSurface height in meters.
layersNoPainted on in order (max 24).
outputNo
keywordsNo
resolutionNoPixels on the long side, 256 to 2048 (default 2048).
normalStrengthNoRelief strength, 0 to 4 (default 1).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / base / properties / maps / additionalProperties
      Added value: +{}
  2. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare the safety profile (readOnly false, destructive false, openWorld false, non-idempotent), and the description goes well beyond them: layers composite in order, ink/spatter sink into base relief and emboss its normal, panel mode auto-creates a phone-sized copy and defers loading by room, material mode returns materialMaps for apply_ops, and a preview image is returned. Minor gap: it does not state limits like the max-24-layer cap that only appears in the schema.

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 and every clause carries real information, but it is delivered as one dense wall of text with no paragraph or bullet structure, making it harder to scan than it needs to be for a 10-parameter tool. Length is largely justified by the tool's complexity.

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?

For a complex generative tool with nested objects and no output schema, the description covers inputs, compositing behavior, both output modes, follow-up placement via the place op, and the returned preview. An agent has everything needed to call it and wire up the result correctly.

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?

With 70% schema coverage but deep nesting, the description compensates by explaining the meaning of nearly every field: tint re-colours while keeping detail, tileSize in meters, stretch vs tile, text sub-fields (size = letter height in meters, tooth = ink skipping weave low spots, dry = patchy ribbon, jitter = typewriter wobble), maxWidth auto-shrink, image width as share of surface, x/y as 0..1 block centre. This adds semantics the schema does not.

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 first sentence gives a specific verb and resource (make a flat surface that looks PRINTED ON a material) and enumerates concrete use cases (canvas quote, poster, sign, label, plaque, book cover). An agent can immediately distinguish this from sibling tools like list_assets, measure, or apply_ops, which are only referenced as supporting steps.

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?

The description explicitly routes: use setId from list_assets vs explicit maps vs flat color; choose output "panel" vs "material" with the consequences of each; and spells out the frame workflow (measure the opening first, oversize the panel by ~0.2 m, place just behind the frame front). When-to-use is stated for every mode.

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