Skip to main content
Glama

Affine Earth Math Court Remote

scene_compose

Compose one stage document from a sea and sealed scene_ingest results. The sea is a 50 x 40 plane (2,000 points, the stage's floor) at z_um on the stage's up axis (the stage is Y-up). Every asset is held to its seal by SceneProvenanceLaw.verify: its usda is read back into a mesh, the mesh's fnv1a must equal the row's mesh_fnv1a and the digest must be the row's sha256, else REFUSED_SEAL; a row re-digested over an inadmissible license re-grades to REFUSED_LICENSE; a HELD row is not placed and is named under held. A placed asset gets the yaw and translation its row recorded. WRITTEN returns usda (the camera and listener lines the Iliad stage writes, then every mesh as int2[] px pairs - never point3f - so the IDE's hologram parser draws it), seal_tsv (the placed rows, each followed by LF), scene_digest (sha256 of seal_tsv, also carried in the stage as affine_scene_digest), meshes, points, faces, placed and held. It fetches nothing, reads no clock and writes nothing on the cell; the caller writes the usda.

Input Schema

NameRequiredDescriptionDefault
seaYesthe sea plane, every value a decimal string of micrometres. e.g. {"half_width_um":"60000000","half_depth_um":"40000000","z_um":"0"}
studyYesthe study the stage belongs to; the default prim is Scene_<study>. e.g. iliad
assetsNooptional: the scene_ingest INGESTED answers to place, in placement order; each needs usda, seal_row and digest exactly as returned. e.g. [{"usda":"<usda>","seal_row":"<seal_row>","digest":"<digest>"}]
cameraNooptional: the hero camera, four x,y,z micrometre triples; absent keys keep the Iliad stage's defaults. e.g. {"eye":"6000000,19000000,86000000","forward":"0,0,-1000000"}

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so extensively: it describes verification via SceneProvenanceLaw.verify, REFUSED_SEAL and REFUSED_LICENSE outcomes, HELD-row handling, placement of yaw and translation, the exact return fields, and that it fetches nothing, reads no clock, and writes nothing on the cell.

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 dense but front-loads its core purpose before moving into behavioral detail. It is longer than ideal for a single paragraph, but nearly every sentence carries operational information and avoids repetition.

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?

Given the complex nested schema, no annotations, and no output schema, the description supplies the missing behavioral and return-value context an agent needs. It explains the verification pipeline, placement rules, failure modes, and output fields, leaving little material ambiguity for correct invocation.

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 the baseline is 3, but the description adds meaningful context beyond the schema: the sea is a 50 x 40 plane at z_um, assets are verified by reading usda back into a mesh, and camera keys fall back to Iliad stage defaults.

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 names a specific verb (Compose) and resource (one stage document) and ties it to sealed scene_ingest results. This clearly distinguishes it from sibling scene_ingest and from study_usda by emphasizing composition of already-sealed material into a stage.

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 establishes that the tool consumes sealed scene_ingest results, implying it is used after ingestion and before caller-side writing of the usda. It does not explicitly name when not to use it or contrast it with alternatives, but the source-of-input constraint is clear.

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