Skip to main content
Glama

Jabbertoon cartoon studio

Build a thing in the 3D builder from steps, and link it

build
Read-only

Builds anything (a character, an animal, a car, a house) in Jabbertoon's 3D builder from steps, as its buttons do: spine, grow, bone (a skeleton, a bone at a time), add a ready part (leg, arm, head, wing, wheel, hat ...), set, copy, remove, look. Checks every step, says what was made (its parts and size) and gives a jabbertoon.com/forge/ link that opens it in the Forge, to change and use in a cartoon, world or game. Over MCP the answer also shows a picture of it from four sides. Steps that start {"op": "new", "kind": "move"} make a move from keys, {"op": "new", "kind": "world"} a world (a level is played to check it), and a game, every one in 3D: "walk" a place to walk at real size (played on foot: told what cannot be reached), or "trench", "space", "surface" or "sky" a game to fly. A refused step says where, why and how to fix it. export_link opens Export, free: STL/3MF to 3D print, glTF (Blender, Unity, Godot), SVG, Minecraft .schem. The steps: get_guide {"topic": "build"}, a game's {"topic": "game"}.

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": "build"
  }
}

Input Schema

NameRequiredDescriptionDefault
buildNoA build to change (the build an answer gave); without it the steps start from a new spine.
stepsNoThe steps, in order: {op: spine | grow | bone | add | set | copy | remove | look, on (a part, or a name an earlier step gave with as), ...}.
blueprintNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / blueprint
      Added value: +{
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / steps / description
      Previous value: -"The steps, in order: {op: spine | grow | add | set | copy | remove | look, on (a part, or a name an earlier step gave with as), ...}."New value: +"The steps, in order: {op: spine | grow | bone | add | set | copy | remove | look, on (a part, or a name an earlier step gave with as), ...}."
  3. Changed1 schema field changed
    • removedInput schema / properties / steps / items
      Removed value: -{
      -  "type": "object"
      -}
  4. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description adds substantial value: every step is checked, failures report where/why/how to fix, the response states the parts and size made and includes a four-side picture plus a Forge link, and game builds are played to verify reachability. What it leaves unclear is persistence — 'make a move' and 'make a world' read like resource creation and sit uneasily with readOnlyHint, which could make an agent unsure whether anything is stored server-side.

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?

The purpose is front-loaded in the first clause, but the text then becomes a single dense run-on cramming op lists, link formats, game kinds, error behavior, and export options into one block. Parenthetical asides and unconverted jargon ('a jabbertoon.com/forge/ link', 'trench', 'sky') add length without proportional clarity. Sentences could be split so that return values, modes, and errors are separate scannable items.

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?

For a complex, nested-input tool with no output schema, the description covers what comes back (parts, size, link, four-side image) and how failures surface, which is the important missing structured information. Two gaps remain: the blueprint parameter is never explained, and the storage/read-only semantics are ambiguous given the 'make a move'/'make a world' framing against readOnlyHint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, so the schema carries most of the weight. The description does add real meaning for the build parameter (the build an answer gave; omit it to start from a new spine) and for the op vocabulary in steps, matching the schema's own listing. The blueprint parameter is a bare object with no description in either the schema or the description, leaving a documented gap.

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 opening clause gives a concrete verb and resource: builds a thing in Jabbertoon's 3D builder from ordered steps, and returns a Forge link. It is clearly distinguishable from siblings like validate, read_blueprint, or make_cartoon because it names the builder, the step vocabulary, and the resulting link. The clarity is diluted by the sprawling enumeration that follows, but the core purpose is unmistakable.

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 routes the agent to concrete alternatives: use export_link for STL/3MF/glTF/SVG/Minecraft output, and get_guide with topic build or topic game to learn the step syntax for games. It also states the condition that selects between modes (op new with kind move/world/game, and walk vs trench/space/surface/sky). It never says when NOT to use this tool versus validate or read_blueprint, so it stops short of full when/when-not guidance.

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