Mascowiz

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

Annotations already disclose the mutation profile (readOnly=false, destructive=false, idempotent=false), so the bar is low. The description adds genuinely new behavioral context — 'Costs 1 credit' — which no structured field carries. It stops short of saying what artifact/ID is returned or whether repeats create duplicates.

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 short sentences, each carrying distinct load: what it produces, what it costs, and when it is warranted. Nothing is repeated and the routing condition is front-loaded enough to guide 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 two-parameter generation tool with no output schema, the description covers purpose, cost, and the gating condition, which is enough to invoke it correctly. It could say what the call returns (a still/asset id) so the agent knows how to chain into animate_mascot.

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%, including a concrete example for 'pose' and the provenance of project_id, so the schema does the heavy lifting. The description adds no syntax, format, or constraint detail beyond it, which is the expected baseline here.

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 ('Draws the approved mascot in a new pose or expression') and immediately frames the output ('as another still to animate from'), which separates it from animate_mascot and create_mascot without needing 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 a clear when-to-use condition: 'Only needed when an animation should start from a different pose than the approved one.' It implies the when-not case (don't call if the approved pose is fine) but never names animate_mascot or approve_mascot as the alternative path.

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 cover the safety profile (not read-only, not destructive, not idempotent, closed-world). The description adds the details an agent actually needs to decide: 10-credit cost, 2-4 minute latency, credit refund on failure, and an async job_id return handle. That is genuine behavioral disclosure layered on top of the annotation hints.

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 capability, then cost/latency/return, then failure behavior. Three tight clauses, no repetition of the title, and every sentence carries decision-relevant information.

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?

There is no output schema, so the description correctly supplies the return contract (job_id for get_animation) plus cost, latency and failure semantics. For a 3-parameter async animation job tool, nothing an agent needs in order to call it and handle the result 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 description coverage is 100%, so all three parameters are already documented in the schema, including the action's 'beginning, middle and end, in place' constraint and the still_id default. The description adds no format or constraint detail beyond that, so the baseline 3 applies.

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 with precise scope: a 5-second seamless loop of the approved mascot performing an action on a transparent background. It also names the downstream sibling (get_animation) that consumes the returned job_id, so the agent can place it in the workflow 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?

The description gives useful operational context (cost, duration, failure handling) and points to get_animation as the follow-up, implying this is the execution step of an animate workflow. However, it never says when to use this versus suggest_animations (for generating action ideas) or add_pose, so alternative selection is left 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 non-read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context beyond them: this call transitions/locks the character into an approved state that unlocks downstream pose and animation work, and it is explicitly free (implying other operations may not be). It does not say whether approval can be revoked.

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 short sentences, front-loaded with the effect, then the cost, then the precondition. The one-word 'Free.' fragment is justified because cost is decision-relevant information an agent cannot get elsewhere.

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 single-parameter state-changing tool with no output schema, the description covers the effect, the precondition, and the cost, which is enough to call it correctly. Remaining gaps are minor: no statement of what failure looks like (e.g., character not ready) or whether approval can be undone.

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 is a single parameter (project_id) with 100% schema description coverage, and the schema even states where to obtain it ('from create_mascot or list_mascots'). The description adds nothing about parameters, so it sits at the baseline for this level of schema coverage.

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 action (locks in the current character) and the concrete downstream benefit (poses and animations can be made from it), which implicitly distinguishes it from add_pose and animate_mascot. It stops short of explicitly naming a sibling as an alternative, so it is clear but not maximally differentiating.

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 an explicit gating precondition: 'Only call this after the user has seen the character and accepted it,' which tells the agent when not to call it. It does not name alternatives or describe what to do if the user has not yet accepted, so it falls short of a full when/when-not/alternative routing.

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 annotations by disclosing a per-call cost ('Costs 1 credit'), the redraw path and its equal cost, the state constraint that the target mascot must be unapproved, and the required human review before approval. None of these side effects, costs, or workflow constraints are available in the 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?

Four short sentences, front-loaded with what the tool does, then cost, then the redraw conditional, then the workflow note. No filler or repetition.

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 correctly states that a picture is returned, covers cost and the redraw/approval flow, and the schema fully documents inputs. Minor gaps remain (image format/size, what happens on insufficient credits), but the agent has enough to call it.

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 all four parameters, setting a baseline of 3. The description adds a meaningful constraint the schema omits: project_id only applies to a mascot that has not yet been approved.

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 ('Draws a mascot character from a description'), plus the output form ('returns the picture') and a rendering constraint ('transparent background'). This clearly separates it from siblings like add_pose, animate_mascot, and approve_mascot.

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 states when to use the project_id parameter ('redraw an existing mascot that has not been approved yet') and gives a workflow instruction ('Show the user the picture before approving'), which implies the approve_mascot handoff. It stops short of naming alternatives or stating when not to call it, but the conditional usage 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 already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered by structured data. The description adds that the balance is per-user ('the user's'), which is useful scoping, but says nothing about auth requirements, caching, or how pricing is refreshed.

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?

A single tight sentence with zero filler and the most important item (credit balance) front-loaded. It is a noun fragment lacking a verb, which is slightly less front-loaded than an explicit 'Returns ...' phrasing, but nothing is wasted.

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 parameters, no output schema, and a simple read-only operation, the description covers everything an agent needs: what comes back (balance, plan, action costs). The absence of return-format detail is acceptable given there is no output schema to expand on.

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 the baseline is 4 and there is nothing for the description to clarify. It correctly adds no parameter discussion, avoiding noise.

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 the resource precisely — the user's credit balance, plan, and per-action costs — which is more specific than the generic tool name 'get_account' suggests. It does not explicitly contrast with siblings, but the mascot/animation siblings are obviously unrelated, so differentiation is implicit rather than stated.

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 only implied: by mentioning 'what each action costs', it hints the agent should call this before spending credits, and it is a zero-param tool so no preconditions exist. There is no explicit when-to-use statement and no named alternative, so it lands at minimum-viable.

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it blocks up to wait_seconds, returns download links only when finished, and those links expire after an hour and must be downloaded into the project. That expiry/download obligation is genuinely useful and not derivable from the 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?

Three short sentences, front-loaded with the core purpose, then the wait behavior, then the return/expiry caveat. Every sentence carries distinct information with no filler.

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?

There is no output schema, so the description must cover return values — it does, describing download links for the main formats plus their one-hour expiry and the need to download them locally. It omits what is returned when the animation is still unfinished (partial progress fields), a minor gap for a polling 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 coverage is 100%, with both job_id and wait_seconds fully documented in the schema (including the default of 45). The description restates wait_seconds implicitly ('waits up to wait_seconds') but adds no format or semantics beyond what the schema already provides, so the baseline of 3 applies.

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 resource (animation progress) and ties it explicitly to the originating sibling, animate_mascot, so it is clearly the polling counterpart to that tool. An agent can distinguish it from animate_mascot, suggest_animations, and get_download without opening any 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?

The description establishes the usage context: call this after animate_mascot to check the animation started there. It does not name a competing alternative or explicitly state when not to use it, but the sequencing with animate_mascot is unambiguous.

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 establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context not in structured data: links expire after an hour, and the tool spans both animation formats and pose stills. It does not describe response shape or auth/rate-limit traits, which keeps it short of a 5.

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?

Two short sentences with no filler, and the core purpose is front-loaded ahead of the expiry caveat. The phrase 'any format of an animation, or the still image of a pose' is slightly winding but not wasteful.

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 correctly signals that the return is a link and adds the crucial expiry fact. Combined with 100% schema coverage and read-only annotations, an agent has enough to invoke it; only the exact response field name is unstated, which is minor.

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%, so format, asset_id, and project_id are all documented in the schema with their enum values and UUID patterns. The description adds no per-parameter detail beyond what the schema already provides, so baseline 3 applies.

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 the resource precisely — a download link for animation formats or a still image — with 'get_download' as the implied verb. It distinguishes itself from siblings like get_animation (metadata) by being explicitly about a downloadable/expiring link, though it doesn't name those siblings directly.

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: call this when you need a file/link for an animation or pose still rather than animation metadata. There is no explicit when-to-use or when-not-to-use guidance, and no mention of which sibling to prefer for related needs (e.g., get_animation for details).

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 genuinely useful behavior beyond that: the ordering (newest first) and the meaning of each stage value (brief, review = waiting for approval, create = approved), which an agent needs to interpret results.

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?

A single front-loaded sentence with no waste; the ordering, contents, and stage glossary are packed efficiently without repetition.

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 rightly carries the burden of explaining return contents, including decoding the stage field, which is the most valuable detail. It stops short of noting pagination or list-size limits, but for a user-scoped mascot list that is a minor 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?

There are zero parameters, so per the rubric the baseline is 4. The description spends its words on return semantics rather than params, which is appropriate here.

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 states the specific resource (the user's mascots) and describes the returned contents (stage, stills, animations), so the agent knows exactly what this call yields. It does not explicitly distinguish itself from siblings like create_mascot or approve_mascot, but the 'list' framing makes the distinction reasonably clear.

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 only implied: an agent infers from the name and zero-parameter schema that this enumerates mascots. The stage semantics ('review = waiting for approval') hint at a natural next step toward approve_mascot, but no when-to-use or alternative is named explicitly.

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: the call is 'Free' (cost disclosure) and the return is exactly three ideas whose 'action' field is directly consumable by animate_mascot. It does not say whether repeated calls are deterministic or cached, but the cost and output-shape notes are substantive.

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 short sentences, front-loaded with the deliverable and the cost before the integration note. Every sentence carries information, though the fragment 'Free.' and 'built on what it already has' are slightly informal for a spec.

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 the work of describing the return (three ideas, each with a passable action) and the cost. It omits the per-idea field structure and whether ideas are deterministic across calls, which are minor for a read-only suggestion 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%, so both parameters (still_id, project_id) are already documented in the schema. The phrase 'built on what it already has' loosely hints at the still_id default of the approved character, but adds no syntax or format detail. Baseline 3 is appropriate when the schema does the work.

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 states a specific resource and output: three animation ideas for the given mascot, tailored to existing assets. It implicitly distinguishes itself from siblings by noting its output feeds animate_mascot, so an agent can separate it from add_pose or get_animation. The verb ('suggest') is only implied rather than stated, which keeps it short of a 5.

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?

There is no explicit when-to-use or when-not-to-use statement, and no named alternative to prefer. The one workflow cue ('each idea's action can be passed straight to animate_mascot') implies this is a precursor to animating, but the agent must infer the condition that selects this tool.

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