Skip to main content
Glama

Jabbertoon cartoon studio

by com.jabbertoon
OverviewDiscussionsAdmin

Make a jabbertoon.com link that opens a move or a character

share_link
Read-only

Turns a Jabbertoon move (a block program of kind "behaviour") or a character into a jabbertoon.com link the person can open in their browser. Everything travels inside the link after the #, so nothing is uploaded or stored, by Jabbertoon or by this tool. A move opens in the block editor, where it plays on a character (links.studio adds it to the person's moves in the cartoon studio); a character opens in the cartoon studio (links.create opens it in the character creator). Give exactly one of program, cartoon or character. No link plays a scene or a whole cartoon yet: for a program of kind "scene" or "cartoon", or a cartoon file, the answer is ok false with error code "not_yet" and no link (validate checks one now). A move or a character is checked first: one with errors gets ok false and the errors (as validate gives them) instead of a link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cartoonNoA saved cartoon file: {"cast"?, "places"?, "program"}. Links that play one are coming in the next release: the answer is not_yet.
programNoA move: a block program {"v": 1, "kind": "behaviour", "scripts": [...]}, as get_move returns. A program of kind "scene" or "cartoon" gets not_yet.
characterNoA character: {"name": "...", "content": {...}}, the content of a character pack (tree, legs, kind, height, footprint, ...), or a whole character pack.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
urlYesThe jabbertoon.com page the link opens (with not_yet, the page that says what links open today).
codeNoThe share code: base64url of the UTF-8 canonical JSON, no padding; the part after #c=.
kindNobehaviour, scene, cartoon or character.
linkNoThe link to give the person.
errorNo
linksNoEvery page that opens it: blocks, studio, create.
notesNo
errorsNoThe errors, in order: the first 50 at most (error_count says how many there are).
lengthNoThe link's length in characters.
warningsNoThe warnings, in order: the first 50 at most (warning_count says how many there are).
error_countNoHow many errors the checks found.
warning_countNoHow many warnings the checks found.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Consistent with readOnlyHint=true and openWorldHint=false, and it goes well beyond them: 'everything travels inside the link after the #, so nothing is uploaded or stored', plus the failure contract (ok false with error code 'not_yet', or validation errors as validate returns them). This is exactly the behavioral detail annotations cannot carry.

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?

Front-loaded with the core action and the no-upload guarantee, then the routing and error rules. It is dense and mostly earns its length, though the not_yet condition is effectively stated twice and partially duplicates the schema property descriptions.

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?

An output schema exists so return values need not be explained, yet the description still covers the ok/error contract, the not_yet path, and the validate-first behavior. Nothing an agent needs to call this correctly with a single program, cartoon or character is missing.

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 cross-cutting semantics the schema cannot express per-property: exactly one of the three must be supplied, and the kind-based routing (behaviour vs scene/cartoon) that determines not_yet. That is genuine added meaning over the individual property descriptions.

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?

States a specific verb+resource (turn a move or character into a jabbertoon.com link) and immediately scopes it against siblings: get_move, validate, and the not-yet-supported scene/cartoon cases. An agent can tell exactly what this produces and what it does not.

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?

Explicit when-to-use and when-not: 'Give exactly one of program, cartoon or character', the not_yet branch for scene/cartoon kinds or cartoon files, and the pointer to validate for checking. It also names the alternative destinations (links.studio, links.create) that select different behavior.

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

All Jabbertoon cartoon studio toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources