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

With no annotations, the description carries the full burden, and it does disclose two genuinely useful traits: the operation costs money ('A paid edit') and it is non-destructive to animation ('every animation keeps working'), plus reversibility via set_props. It does not say whether the result is immediate or a queued job (siblings list_jobs/wait_for_job suggest async work), nor what is returned or what permission level is required.

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 essentially one dense sentence plus a short cost note, front-loading the core action and examples before the set_props caveat. The clause 'shown, so it can be switched off later with set_props and the mascot is as it was' is grammatically tangled and costs 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?

For a three-parameter, annotation-free mutation with no output schema, the description covers cost, reversibility, and expected input style, which is reasonable. It still leaves the required id field undefined and does not say whether the edit is synchronous or returns a job handle, which matters given the list_jobs/wait_for_job siblings.

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 only 33%, so the description must compensate. The quoted phrases ('a small frying pan in the right paw', 'a golden crown') usefully illustrate the style expected for the required description parameter, but the required id parameter is unexplained in both schema and description, and there is no guidance on the 300-character limit or how name is derived.

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 concrete verb and resource: draw a prop the mascot holds or wears as part of itself, with two illustrative examples ('a small frying pan in the right paw', 'a golden crown'). It also implicitly separates itself from set_props, the tool that removes the prop, so an agent can place it among its siblings, though the wording of that relationship ('shown, so it can be switched off later') is slightly muddled.

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 rather than prescribed: the agent learns to call it when adding a held/worn item and that set_props later removes it. There is no explicit statement of when not to use it, no prerequisite checks (e.g. mascot existence or plan/credit availability) beyond the passing note that it is 'a paid edit'.

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