Skip to main content
Glama

Jabbertoon cartoon studio

Make a talking cartoon from a plain script, in one call

make_cartoon
Read-only

The quickest way to a cartoon: send the script as people write one, a line each, Name: what they say, and get the jabbertoon.com link that opens it in the editor ready to play and to record as a video (free, no account). Read too: (happy, waves) in a line; [Leo walks to Mia] on a line of its own; Place: Beach (another later starts the next scene); Cast: Mia (cat). Our characters come by name (Sunny, Grump, Ria, Bob, Kiki) and a new name becomes one of our 3D cast. What was not used is in notes. Example: {"script": "Place: Beach\nMia (cat): (worried) Have you seen my hat?\nLeo: (looks around) Is it on that crab?"}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "script": "<script>"
    },
    "name": "make_cartoon"
  }
}

Input Schema

NameRequiredDescriptionDefault
castNoWho each name is: {"Mia": "cat", "Leo": "pirate"}.
placeNoWhere it is, by name: Beach, City, Space, Old Keep... (else its Place: line, else the Meadow).
titleNoIts name (else the script's Title: line).
scriptYesThe script: a line each, Name: what they say.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.2/5.0
Behavior1/5

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

The annotations declare readOnlyHint=true, but the description says it makes a cartoon, can turn a new name into one of the 3D cast, and returns an editor link ready to record as a video. That describes creation and possible cast mutation, which contradicts the read-only annotation.

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 front-loaded with the core outcome and remains information-dense, with the example earning its place. Some phrasing is run-on and the 'Read too:' list is awkward, but it does not become bloated.

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?

It explains the input format, return link/editor behavior, free/no-account access, notes for unused content, defaults, and cast behavior. It still lacks routing guidance among sibling tools and error or validation behavior, but the core call context is largely complete.

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

Parameters5/5

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

Although schema description coverage is 100%, the description adds substantial meaning: the script grammar includes Name: dialogue lines, parentheticals, bracketed stage directions, Place: and Cast: lines, scene breaks, and the built-in character list. The example also clarifies how the script, cast, place, and title parameters interact.

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 a specific verb and resource: send a script, get a jabbertoon.com link that opens a cartoon in the editor. It is very clear what the tool does, but it does not distinguish itself from siblings such as build or validate.

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

Usage Guidelines2/5

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

It says this is 'the quickest way to a cartoon,' but gives no explicit when-to-use or when-not-to-use guidance against alternatives like validate, build, list_characters, or get_guide. An agent must infer whether to validate a script first or use another creation path.

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