Jabbertoon cartoon studio

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 real context beyond them: the exact composition of the response (program JSON, readable text, length, page, links) and a documentation URL for the program language. It does not mention failure modes for an unresolvable id, but the disclosure is solid for a read 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?

Three sentences, front-loaded with the return value, then accepted identifiers, then the authoring workflow. Every sentence does work, though the inline docs URL and the full re-listing of identifier formats make it slightly longer than strictly necessary.

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 an output schema present, the description need not explain return values, yet it usefully previews them. Identifier formats, the language docs link and the authoring workflow together give an agent enough to call this correctly. Only error handling for a bad move reference is left unaddressed.

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 description coverage is 100% and the single parameter already documents the id, short name and slug forms. The description largely restates those forms, adding only the minor clarification that the last part of the page URL is acceptable. Baseline 3 is appropriate when the schema carries the semantics.

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 Jabbertoon move') and enumerates the payload: JSON block program, readable text, length, page and links. It is clearly distinguishable from list_moves (enumerate many), validate and share_link, which are named as downstream steps rather than aliases.

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?

The closing sentence gives an explicit workflow: fetch a move, change the program, check it with validate, then make a link with share_link. That routes the agent to the right siblings for the authoring path. It does not state when to prefer get_move over list_moves or what to do if the id is unknown, so it stops short of full when/when-not coverage.

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 real behavioral context beyond that by describing the shape and semantics of the payload (cast keyed by ids, look.template lookup, and the presence of a full cartoon_example). It does not discuss pagination, auth, or limits, but for a zero-parameter read-only listing that is a minor gap.

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 in the opening sentence and every subsequent clause carries real information (field list, cast semantics, worked example, sibling pointer). It is dense and reads as a single long paragraph with an embedded JSON snippet, which is slightly heavier than needed for a no-argument listing tool.

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 zero parameters, an output schema present, and simple annotations, the description supplies everything an agent needs: what the six characters are, what fields each carries, how a cast entry references a character, where to get styles, and that a full example cartoon is included. Nothing essential 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?

The tool takes no parameters, so there is nothing for the description to disambiguate and the baseline is 4. The schema is an empty object with additionalProperties=false, consistent with the description's framing as a pure listing call.

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 first sentence gives a precise verb+resource (lists the six ready-made cartoon characters) and even enumerates them, plus the fields returned for each (legs, views, colour slots, page, studio/creator links). It also cross-references list_looks for styles, so an agent can separate it from the sibling tools without opening a 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?

Usage is conveyed through context rather than an explicit 'use this when' clause: the description explains that a cartoon's cast is keyed by ids its blocks name in 'who' and that each entry draws via look.template, which tells the agent when this data is needed. The pointer to list_looks for styles is helpful, but there is no explicit exclusion or alternative-selection rule.

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 behavioral detail by disclosing the size and composition of the result (six styles, three shapes) and that each entry carries a page URL and a studio deep-link.

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 core enumeration is front-loaded in the first clause; the trailing example object is longer than strictly necessary but directly shows how the returned values are consumed in a cast entry, which earns its place.

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 zero-argument, read-only enumeration with an output schema already present, nothing an agent needs is missing — the description even names the enumerations and the shape of each entry.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing parameter-wise for the description to clarify, and it correctly spends its words on return contents instead.

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 names a specific resource (Jabbertoon art styles/looks plus body shapes) and enumerates the exact returned values (flat, outlined, soft, storybook, bold, crayon; classic, big head, tall), so an agent can distinguish it immediately from list_characters, list_moves, or get_move.

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?

Usage is implied by the content description — you call this to discover valid look.style/look.shape values before building a cast entry — but it never states when to prefer this over siblings like list_characters or validate, nor any 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 declare readOnlyHint=true and openWorldHint=false. The description adds substantial behavioral context beyond that: the per-move fields returned (id, description, length, page, editor/studio links), the fact that moves are not tied to one character and play across six subjects, and that some suit certain bodies better. It does not cover pagination, but is otherwise rich.

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 and final sentences are dense and packed with parenthetical asides that a reader must parse carefully. The semantic-search explanation is valuable but verbose, and the sentence length makes it harder to skim than a tighter version would be.

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?

Given an output schema exists, the description needn't detail return values, though it helpfully describes the per-move fields anyway. It covers scope, cross-character behavior, the search semantics and filter echo. It omits anything about result limits, ordering, or error cases, which keeps it from being fully complete.

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 beyond the schema by explaining the OR-of-words match logic, that synonyms map to move names (dance→Groove, scared→Cower, sleep→Breathe/Still), that notes flag meaning-based hits and feeling-linked faces, and that the applied filter is echoed in 'filters'. This is genuine added semantics.

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 opens with a specific verb and resource ('Lists the ready-made moves (animations) a Jabbertoon cartoon character can do') and immediately enumerates concrete examples (walk in, wave hello, hop, bow, slump, talk). It distinguishes itself from the sibling get_move by clearly being the catalog listing versus fetching a single move's program.

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 explicitly routes to get_move for a move's program, indicating when to use the sibling instead. It doesn't state exclusions for list_characters or list_looks, but the boundary with the most relevant alternative is clear.

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 say readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false, which an agent cannot fully interpret. The description adds the crucial behavior: the submission is persisted and read by a human, and it imposes a privacy rule (no names, emails, or details about the person being helped). It also confirms nothing is destroyed, consistent with destructiveHint=false.

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 core purpose, followed by a dense but value-bearing enumeration of problem kinds and the persistence/privacy caveats. The long first sentence is justified because it grounds the enum values in real scenarios, though it 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?

An output schema exists so return values need no explanation, and the description covers the remaining gaps an agent needs: when to file, what gets retained and reviewed by a person, and the privacy constraint. Nothing material is missing for a 4-parameter, 1-required reporting tool.

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 description coverage is 100% and each parameter already has its own description, so the schema carries the semantic load. The description recaps the fields (kind, item, the request that produced it, and your note) but adds no syntax or format guidance beyond what is already documented, making the baseline 3 appropriate.

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+resource (report a problem with Jabbertoon's tools or content to the people who run it) and explicitly differentiates from siblings with 'Unlike the other tools, this one keeps what you send.' An agent can immediately tell this is the feedback/escalation tool rather than a query or validation tool.

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?

Enumerates concrete when-to-use triggers (wrong tool answer, validator false positive/negative, wrong-looking move, dead link, incorrect docs, missing content) that map directly to the kind enum. It stops short of naming when NOT to use it or pointing to a sibling alternative (e.g., use validate to check a program yourself), so it is clear context without explicit 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?

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.

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.

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.

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.

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.

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.

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, yet the description still adds real behavior: 'Nothing you send is stored or logged,' the distinction that warnings do not stop playback, and concrete examples of what warnings flag (dead hats, missing moves, undrawable looks). It goes beyond the annotations rather than restating them.

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 in the first clause, but the body is one very long paragraph that inlines an entire cartoon JSON example and re-narrates language details already linked in the schema docs. It is information-dense but poorly chunked and heavier than needed for 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?

For a complex, nested-schema tool with an output schema present, the description is thorough: it explains what gets validated, the one-of-four constraint, the retry workflow, warning semantics, and privacy behavior. Return-value details are correctly left to the output schema, leaving little an agent needs that 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% and each parameter already carries format docs, so the baseline is 3; the description adds genuine value by supplying a worked cartoon example, clarifying 'who names a cast id' and that scripts start with a scene hat, which deepens understanding of the nested structures beyond the schema text.

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 enumerates exactly what resources are validated: a block program, character, pack, or saved cartoon file. It ties itself to 'Jabbertoon's own validator' and clarifies it runs the same checks as the studio/creator/editor, so an agent can place it immediately against siblings like get_move or 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?

Explicitly instructs 'Give exactly one of program, character, pack or cartoon' and gives a workflow: 'Fix the errors and call validate again until ok is true.' It also points to get_move for ready-made moves. It lacks explicit when-not guidance, but the mutual-exclusion rule and retry loop are strong, actionable context.

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