Skip to main content
Glama

Jabbertoon cartoon studio

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

share_link
Read-only

Turns a cartoon, a scene, a move or a character into a jabbertoon.com link: it opens in the editor (a move in its move maker). It all travels after the #: nothing is uploaded or kept. All but a character's end with &from=ai (the page says an AI helper wrote it). One with errors gets them instead. Give one of cartoon, program, character or file. Example: {"program": {"v": 1, "kind": "behaviour", "scripts": [{"body": [{"op": "hop"}]}]}}.

Input Schema

NameRequiredDescriptionDefault
fileNoOn your own computer only: a file's name in the output folder.
cartoonNoIts program, a cartoon file {cast, places?, program}, or its screenplay text (read on your own computer only).
programNoA move (kind "behaviour"), a scene or a cartoon program.
characterNoYour own character, {"name", "content"}, or a character pack.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / cartoon / description
      Previous value: -"A saved cartoon file: {\"cast\"?, \"places\"?, \"program\"}. Links that play one are coming in the next release: the answer is not_yet."New value: +"Its program, a cartoon file {cast, places?, program}, or its screenplay text (read on your own computer only)."
    • changedInput schema / properties / cartoon / type
      Previous value: -"object"New value: +[
      +  "object",
      +  "string"
      +]
    • changedInput schema / properties / character / description
      Previous value: -"A character: {\"name\": \"...\", \"content\": {...}}, the content of a character pack (tree, legs, kind, height, footprint, ...), or a whole character pack."New value: +"Your own character, {\"name\", \"content\"}, or a character pack."
    • addedInput schema / properties / file
      Added value: +{
      +  "description": "On your own computer only: a file's name in the output folder.",
      +  "maxLength": 255,
      +  "type": "string"
      +}
    • changedInput schema / properties / program / description
      Previous value: -"A move: a block program {\"v\": 1, \"kind\": \"behaviour\", \"scripts\": [...]}, as get_move returns. A program of kind \"scene\" or \"cartoon\" gets not_yet."New value: +"A move (kind \"behaviour\"), a scene or a cartoon program."
    • changedOutput schema / (root)
      Previous value: -{
      -  "$defs": {
      -    "problem": {
      -      "properties": {
      -        "code": {
      -          "type": "string"
      -        },
      -        "fix": {
      -          "type": [
      -            "string",
      -            "null"
      -          ]
      -        },
      -        "says": {
      -          "type": "string"
      -        },
      -        "where": {
      -          "type": [
      -            "string",
      -            "null"
      -          ]
      -        }
      -      },
      -      "required": [
      -        "code",
      -        "where",
      -        "says",
      -        "fix"
      -      ],
      -      "type": "object"
      -    }
      -  },
      -  "properties": {
      -    "code": {
      -      "description": "The share code: base64url of the UTF-8 canonical JSON, no padding; the part after #c=.",
      -      "type": "string"
      -    },
      -    "error": {
      -      "$ref": "#/$defs/problem"
      -    },
      -    "error_count": {
      -      "description": "How many errors the checks found.",
      -      "type": "integer"
      -    },
      -    "errors": {
      -      "description": "The errors, in order: the first 50 at most (error_count says how many there are).",
      -      "items": {
      -        "$ref": "#/$defs/problem"
      -      },
      -      "type": "array"
      -    },
      -    "kind": {
      -      "description": "behaviour, scene, cartoon or character.",
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    },
      -    "length": {
      -      "description": "The link's length in characters.",
      -      "type": "integer"
      -    },
      -    "link": {
      -      "description": "The link to give the person.",
      -      "type": "string"
      -    },
      -    "links": {
      -      "description": "Every page that opens it: blocks, studio, create.",
      -      "type": "object"
      -    },
      -    "notes": {
      -      "items": {
      -        "type": "string"
      -      },
      -      "type": "array"
      -    },
      -    "ok": {
      -      "type": "boolean"
      -    },
      -    "url": {
      -      "description": "The jabbertoon.com page the link opens (with not_yet, the page that says what links open today).",
      -      "type": "string"
      -    },
      -    "warning_count": {
      -      "description": "How many warnings the checks found.",
      -      "type": "integer"
      -    },
      -    "warnings": {
      -      "description": "The warnings, in order: the first 50 at most (warning_count says how many there are).",
      -      "items": {
      -        "$ref": "#/$defs/problem"
      -      },
      -      "type": "array"
      -    }
      -  },
      -  "required": [
      -    "ok",
      -    "url"
      -  ],
      -  "type": "object"
      -}New value: +null
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely useful context beyond them: all state travels in the URL fragment, "nothing is uploaded or kept," non-character links carry &from=ai, and error payloads are encoded in the link. That is real behavioral disclosure (privacy, provenance flag, failure mode) rather than restatement.

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

Conciseness3/5

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

The purpose is front-loaded and the description is short, with no filler sentences. However, telegraphic fragments like "It all travels after the #" and "One with errors gets them instead" cost comprehension for the space they save, so brevity here partly reads as under-specification.

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?

With no output schema, the description does carry the return-value burden and handles it: the output is a jabbertoon.com link that opens in the editor, or a link carrying errors when generation fails. For a 4-input, one-of union with nested objects, the coverage is sufficient, though the error case could be spelled out more concretely.

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, and the description clears that bar: it explains what a "move" means ("kind behaviour", in its move maker), states that exactly one of the four inputs may be given, and supplies a concrete program payload example. The nested-object shapes are still mostly left to 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?

"Turns a cartoon, a scene, a move or a character into a jabbertoon.com link: it opens in the editor (a move in its move maker)" states a specific verb (turns X into a link) and resource/scope, so the transformation is unambiguous. It does not, however, differentiate itself from siblings like build or validate, which sit in the same authoring workflow.

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?

"Give one of cartoon, program, character or file" gives an input-selection rule, and the editor-opening behavior implies the use case is producing a shareable link. But there is no explicit when-to-use / when-not-to-use guidance relative to build or validate, so the routing information is only implied.

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