Skip to main content
Glama

Affine Earth Math Court Remote

twin.robotics.evaluate_exact_ik

Exact integer FORWARD pose of a fixed seven-piece avatar rig - it takes no target pose and derives no joint values from one; that solver is not built here. The rig is the head and its eyes: piece ids 0-6 are head, left eye globe, right eye globe, left upper lid, left lower lid, right upper lid, right lower lid. Post the piece_id to report; pieces is OPTIONAL - rows (piece_id, parent_id, origin_*_milli, rotation_milli_deg, extent_milli as decimal strings) that override the built-in rest chain by id, and with pieces absent or [] the court composes the built-in seven-piece rig as declared; the court composes each local frame from the sovereign anchor (or relative_to_head) and returns that piece's pose in whole milli-units - PROVEN_EXACT_IK with the pose, or a refusal naming the piece or field. Zero floats, one Q16 normalization point, byte-identical on arm64 and wasm32. A declared chain solved toward a target pose is not built here (decided 2026-09-26: such a chain answers only where an exact closed form exists and refuses by name otherwise; a later release builds it).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
piecesNodeclared PieceFrame rows as decimal strings. e.g. [{"piece_id":"3","rotation_milli_deg":"15000"}]
piece_idYesdecimal string, the piece to solve for. e.g. 3
relative_to_headNostate the pose relative to the head (camera-free) rather than the anchor. e.g. true

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changed
    • changedInput schema / properties / piece_id / description
      Previous value: -"decimal string, the piece to solve for"New value: +"decimal string, the piece to solve for. e.g. 3"
    • changedInput schema / properties / pieces / description
      Previous value: -"declared PieceFrame rows as decimal strings"New value: +"declared PieceFrame rows as decimal strings. e.g. [{\"piece_id\":\"3\",\"rotation_milli_deg\":\"15000\"}]"
    • changedInput schema / properties / pieces / items / properties / extent_milli / description
      Previous value: -"decimal string"New value: +"decimal string, extent in millimetres, e.g. 12"
    • changedInput schema / properties / pieces / items / properties / origin_x_milli / description
      Previous value: -"decimal string"New value: +"decimal string, origin X in millimetres, e.g. 0"
    • changedInput schema / properties / pieces / items / properties / origin_y_milli / description
      Previous value: -"decimal string"New value: +"decimal string, origin Y in millimetres, e.g. 0"
    • changedInput schema / properties / pieces / items / properties / origin_z_milli / description
      Previous value: -"decimal string"New value: +"decimal string, origin Z in millimetres, e.g. 0"
    • changedInput schema / properties / pieces / items / properties / parent_id / description
      Previous value: -"decimal string"New value: +"decimal string, the id of the parent piece, e.g. 0 (the head)"
    • changedInput schema / properties / pieces / items / properties / piece_id / description
      Previous value: -"decimal string"New value: +"decimal string, one of the seven declared ids 0..6 (0 head, 1 eye_globe_l, 2 eye_globe_r, 3 lid_upper_l, 4 lid_lower_l, 5 lid_upper_r, 6 lid_lower_r), e.g. 3"
    • changedInput schema / properties / pieces / items / properties / rotation_milli_deg / description
      Previous value: -"decimal string"New value: +"decimal string, rotation in milli-degrees, e.g. 15000 for 15 degrees"
    • changedInput schema / properties / relative_to_head / description
      Previous value: -"state the pose relative to the head (camera-free) rather than the anchor"New value: +"state the pose relative to the head (camera-free) rather than the anchor. e.g. true"
    • changedInput schema / required
      Previous value: -[
      -  "pieces",
      -  "piece_id"
      -]New value: +[
      +  "piece_id"
      +]
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does much of it: it discloses the success output (PROVEN_EXACT_IK with the pose), the failure mode (a refusal naming the offending piece or field), the determinism guarantee (zero floats, one Q16 normalization point, byte-identical on arm64 and wasm32), and the write-free nature of the operation. Missing only explicit permission/auth context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sprawling paragraph with multiple em-dash clauses, repeated phrasing ('the court composes...' twice), and cryptic coinages. The most important fact for selection (this is the FORWARD solver, not IK) is present but buried amid jargon rather than front-loaded cleanly.

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?

There is no output schema, so the description must and does explain the return contract (pose envelope PROVEN_EXACT_IK or a named refusal). For a 3-parameter, nested-free tool whose annotations are absent, this is close to sufficient; only auth/permission context is absent.

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 3 is the floor, but the description adds genuine semantics the schema does not: pieces rows override the built-in rest chain by id, and absent/empty pieces selects the composed built-in rig. It also explains relative_to_head as camera-free head-relative output. This goes beyond the per-field 'decimal string' examples in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states precisely what the tool computes: the exact integer forward pose of a fixed seven-piece avatar rig, and explicitly declares what it is not (the IK solver that derives joints from a target pose). That disambiguation is valuable even though the tool name 'evaluate_exact_ik' invites the opposite expectation. The heavy idiosyncratic vocabulary ('court composes', 'sovereign anchor') slightly muddies the core statement.

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

Usage Guidelines3/5

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

It gives real conditional guidance: pieces is optional and when absent/[] the built-in seven-piece rig is used, and relative_to_head switches the reference frame. It also says the target-pose chain is not built here. But it never names an alternative sibling tool or a clean when-to-use rule, so routing depends on the agent parsing dense prose.

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