Skip to main content
Glama

text_mesh

Destructive

Create 3D text as a closed mesh or engrave letters into an existing mesh surface, controlling size, depth, plane, alignment, font, and bevel.

Instructions

Make a text label as a closed mesh, or engrave text into a mesh. size is the height of a capital letter and depth the thickness, in metres. \n starts a new line. plane: XZ stands upright and reads from the front (-Y), XY lies flat and reads from above, YZ stands and reads from +X. The back face is on the plane. at is the anchor in the world (the origin when empty) and the object origin; align puts the middle, the left end or the right end of the text there; vertically the text is centred. font is a path to a .ttf or .otf file. The built-in font has Latin and Cyrillic; a font without a glyph shows nothing for that character. bevel rounds the edges (0 to depth/2). The same name replaces the earlier text. on_object (a mesh) puts the text on its surface: a ray through at along the plane normal finds the first hit, and the text lands offset metres above it (a decal that does not z-fight). The text stays flat: use it on flat or nearly flat surfaces. engrave=true cuts the letters depth deep into on_object instead, with the checks and clean-up of boolean; no text object stays and bevel is ignored. The mesh must be closed. The answer has the volume before and after.

Input Schema

NameRequiredDescriptionDefault
atNo
fontNo
nameNotext
sizeNo
textYes
alignNocenter
bevelNo
depthNo
planeNoXZ
offsetNo
engraveNo
on_objectNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description goes well beyond them, disclosing that the same `name` replaces earlier text, that engrave removes the text object and ignores `bevel`, that the target mesh must be closed, that the decal avoids z-fighting, and that the response reports volume before and after.

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?

It is a dense block of prose but virtually every clause carries new information needed to call the tool correctly, and it is front-loaded with the dual purpose. Structure is a bit uneven — a long run-on rather than clearly partitioned sections — which keeps it off a 5.

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 12-parameter mutation tool with no output schema and no schema descriptions, the description covers geometry interpretation, units, orientation, failure modes (missing glyphs, non-closed mesh, curved surfaces), and the returned volume data. An agent has everything needed to invoke it 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?

Schema description coverage is 0% across 12 parameters, so the description carries the whole burden and does: it defines size as cap height in metres, depth as thickness, the meaning of each plane enum orientation, `at` as world anchor plus object origin, `align` as horizontal placement with vertical centring, `bevel` bounds (0 to depth/2), `font` as a .ttf/.otf path with built-in Latin/Cyrillic and missing-glyph behaviour, and `offset` in metres above the hit.

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 opening sentence gives a specific verb and resource with two clear modes: 'Make a text label as a closed mesh, or engrave text into a mesh.' No sibling tool produces text geometry, so this is immediately distinguishable.

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?

It explains the condition for the engrave path (cuts letters into on_object, with boolean checks, no text object remains) versus the decal path, and warns to use on_object only on flat or nearly flat surfaces. It does not name alternative tools or state when not to use this tool, so it stops short of a full 5.

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