Jabbertoon cartoon studio

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

The description says the tool 'Builds anything', makes moves/worlds/games, opens Export, and produces editable links, all of which imply mutation and side effects. The annotations declare readOnlyHint=true, which directly contradicts the described write behavior and export functionality.

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

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

The opening sentence is front-loaded with the core purpose, but the description is a dense run-on with many parentheticals and asides. It contains useful details, yet it is difficult to scan and some phrases, such as 'a game's {"topic": "game"}', are awkwardly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex nested-step tool with no output schema, the description covers a lot: step validation, returned link, four-side picture over MCP, export formats, and guide topics. Its main completeness gap is that the mutation semantics are described without reconciling them to the read-only annotation.

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

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

Schema coverage is 100%, so the schema already documents both `build` and `steps`. The description adds some useful step-form examples, such as {"op": "new", "kind": "move"} and {"op": "new", "kind": "world"}, but much of its parameter discussion is embedded in long prose rather than clearly mapped to the two parameters.

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

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

The description clearly states a specific verb and resource: building a 3D object in Jabbertoon's builder from ordered steps, including moves, worlds, and games. It lists the supported operations (spine, grow, bone, add, set, copy, remove, look) and names get_guide as a related tool, though it does not sharply differentiate itself from sibling tools such as validate.

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

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

It gives some contextual guidance: use get_guide {"topic": "build"} for steps and {"topic": "game"} for games, and describes specific step kinds for moves, worlds, and games. However, it does not explicitly say when to use build versus validate or other siblings, nor does it state clear exclusions.

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

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

Annotations already cover read-only and closed-world, but the description adds genuinely new behavioral facts: output is Markdown capped under 20,000 characters, omission of topic defaults to 'start', and coordinate/time unit conventions (x,y as 0-1 shares of stage, ground at 0.92, seconds). It loses a point because the topic list in prose omits several enum values (play, shapes, examples, keys, fight), leaving a mild inconsistency an agent must resolve from the schema.

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

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

Front-loaded with the imperative 'Call this first' and the return format, then the topic glossary, then units and an example. Dense but nearly every clause carries information; the topic parentheticals are the bulk and are justified by helping selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must characterize the return value — it does so with format and size bound, plus unit conventions for the content it describes. Adequate for a one-parameter documentation tool, with only the topic-coverage mismatch against the enum as a gap.

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

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

Schema coverage is 100% and the enum names the values, but the description goes further by glossing what each topic contains (cartoon = JSON program, export = STL/3MF/glTF/SVG/Minecraft, song = editor's own file), which genuinely aids topic selection. The gloss list does not match the enum exactly, so completeness of the explanation is imperfect.

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

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

States a specific verb and resource ('Returns one topic of Jabbertoon's guide as Markdown') and enumerates the topics, so an agent knows this is the documentation tool rather than an action like build or validate. The 'Call this first' opener also frames its role in the toolset.

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

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

Explicitly says to call it first, and the schema note plus the 'start' topic description ('names the others') tells the agent how to bootstrap. No alternative needs mentioning because no sibling serves the same purpose.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes beyond them by disclosing the exact payload ( program, screenplay rendering, duration in seconds, settings with units) and by noting that moves come 'ready-made' and can be used as a starting point for authoring. It does not mention size limits or error behavior for an unknown move reference.

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

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

Front-loaded with the return contents, then the naming rules, then the authoring workflow, then a call example. Every sentence earns its place, though the run-on enumeration of return fields is dense and could be split for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must carry the return contract, and it does — itemizing every field the agent will receive. Identifier formats and the follow-on validate step are covered. Missing only edge-case behavior (what happens if the reference is ambiguous or unknown).

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

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

Schema coverage is 100% and the schema already says the value is the id, short name or page slug as list_moves gives them. The description still adds real value by spelling out the three accepted forms and giving a concrete id example ('c4c:beh:wave_hello') plus a call example, removing any guessing about format.

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

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

States a specific verb and resource ('Returns one ready-made move') and then enumerates exactly what comes back: block program JSON, screenplay text, length in seconds, works-on target, settings with units, page and links. The word 'one' plus the enumerations clearly separates it from the sibling list_moves.

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

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

Gives a clear authoring workflow: 'To write your own move, start from one, change it, then validate it,' routing the agent to the sibling validate tool. It also explains the three accepted identifier forms, but never states when not to use this tool or what to use instead for bulk retrieval.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful inventory context (which characters, which voices, cartoon_example) but is vague about the actual return shape ('the designed entry a cast entry gives it') and says nothing about freshness, limits, or how the cast relates to the write path.

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

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

It is front-loaded with the core purpose, but the middle sentence is a long, grammatically tangled run-on that is hard to parse. Several phrases ('the designed entry a cast entry gives it') add words without adding clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must carry the return-value burden; it does list the main contents (cast, voices, cartoon_example, flat templates) but explains their structure opaquely. Enough to know roughly what comes back, not enough to know the shape.

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

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

There are zero parameters, so the baseline is 4. The description even shows the object shape an agent would supply when writing a cast, which is helpful orientation even though it is not a parameter of this tool.

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

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

States a specific verb and resource ('Lists the cast in 3D') and enumerates the actual members (bob, ria, sunny, sam, lee, rose; dog, cat, fox, etc.), so an agent can distinguish it from list_looks and list_moves. It does not explicitly name a sibling it replaces, but the character/voice inventory makes the scope unambiguous.

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

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

'Call it to write a cast' plus a concrete JSON sample implies the usage context clearly, but there is no statement of when NOT to call it or which sibling to prefer for other listing needs (looks, moves). Adequate but leaves the alternatives to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the full shape of returned records, the fuzzy/semantic nature of q matching, and how the result is consumed in a does block. It omits pagination or ordering behavior, but for a safe read tool this is solid added context.

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

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

Front-loaded with the resource and returned fields, followed by search semantics and a compact example. The embedded does-block JSON is slightly tangential to a listing tool, but it is short and directly illustrates why the ids returned here matter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-shape burden and does so by enumerating every field, including units on settings. Combined with the search semantics explanation, an agent has enough to invoke and interpret the result; only ordering/pagination detail is absent.

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

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

Schema coverage is 100% and the q parameter is already documented, so the baseline is 3. The description goes further by explaining that q matches words OR meaning ("dance finds Groove, scared finds Cower") and gives a concrete example, adding semantics the schema does not carry.

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

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

States a specific verb (Lists) and resource (ready-made cartoon moves) and enumerates the returned fields (id, name, length, bodies, settings, page, links). It is clearly distinct from list_characters and list_looks by resource, though it never explicitly contrasts itself with the singular get_move sibling.

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

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

Gives clear usage context: omit q for every move, use q for word/meaning search, and shows how a returned move is played via a does block. It stops short of naming an alternative tool (e.g. get_move) for retrieving a single move, so it is context-rich but not a full when/when-not routing guide.

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

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

Annotations only declare the write/non-idempotent profile; the description adds the crucial facts that the payload is persisted and read by a human, and imposes an explicit privacy prohibition ('Never put the cartoon, a name, an address or anything about the person you help in it'). That is exactly the behavioral context an agent cannot get from structured fields.

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

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

Front-loaded with the purpose, then conditions, persistence, privacy rule and an example — every block earns its place. The first sentence is a long run-on with stacked clauses and a redundant parenthetical on hard_because, which slightly hurts readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters, no output schema and a privacy-sensitive payload, the description covers what to send, what must be excluded, and that a human will read it. It does not say what the tool returns or whether submission is acknowledged, which is the only real gap given no output schema exists.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes further by grouping the fields that get saved (kind, tool, code, where, item, note, hard_because) and by giving a worked example payload with realistic values. It adds moderate meaning over the schema but does not explain os/cli_version or the item vs where distinction.

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

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

States a specific verb and resource ('Tells the people who make Jabbertoon something is wrong') and enumerates the concrete problem categories it handles, making it immediately distinguishable from read-only siblings like validate, get_move or list_moves. An agent can tell what this tool is for without opening the schema.

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

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

Gives clear triggering conditions ('a wrong answer, a check that refused a good cartoon or passed a bad one, a move that looks wrong, a link that does not open, wrong docs, something missing') and explicitly carves out the hard_step sub-case. It also contrasts the tool with siblings ('Unlike the other tools, it keeps what you send'), though it never states when *not* to file a report.

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

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.

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.

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.

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.

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.

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.

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the retention policy ('Nothing you send is kept'), the exact error/warning object shape {code, where, says, fix, url}, the presence of did_you_mean and an RFC 6902 patch 'when certain,' the viewer-facing issue categories, and what repair:true returns. This is unusually rich behavioral disclosure for a read-only tool.

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

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

Front-loads the purpose and return contract with almost no filler, and the example is tacked on usefully at the end. The middle sentences are dense and run-on, which costs a point but not readability of the key facts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and a nested-object, six-parameter input, the description carries the full return-value burden and does so: error fields, warnings, viewer issues, summary contents, and the ok-path canonical program plus link. Nothing an agent needs to invoke or interpret it is missing.

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

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 genuine meaning: the mutually alternative inputs (cartoon/program/pack/character/file), the note that get_move supplies ready-made programs, and the semantics of repair:true applying 'every certain patch.' It adds value over the schema rather than repeating it.

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

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

States a specific verb (checks) and resource (cartoon/program/pack/character/file) plus the timing constraint 'before anyone sees it,' which distinguishes it from build and share_link without naming them. It is clear what the tool does, though sibling differentiation is only implicit.

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

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

'Give one of cartoon, program, pack, character or file' frames the calling context, and 'before anyone sees it' implies pre-publication validation. It offers a concrete example (list_characters' cartoon_example) but does not explicitly say when not to use it versus build or get_guide.

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