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

Even though annotations all default to false, the description discloses key behavioral traits: the action queues artwork for moderation, catalog listing is not immediate, and the system fetches print files server-side. This goes beyond what annotations provide and gives the agent a realistic model of effects and timing.

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 description is direct and information-dense, starting with action and then covering inputs, constraints, and behavior in a compact paragraph. It uses punctuation effectively (colons, semicolons, parentheses) to pack several ideas without becoming bloated. Minor loss for the run-on feel in the middle section, but no wasted sentences.

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 the tool has 7 parameters, an output schema, and moderate complexity, the description covers the essential operational context: the two input modes, optional parameters, layout choices, resolution requirement, and the moderation/catalog delay. It does not need to detail return values since an output schema exists. This is a complete, self-contained description for an agent to select and invoke correctly.

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?

With 100% schema coverage, baseline is 3, but the description adds meaningful context: it clarifies the front/session_id mutual exclusion ('front OR session_id (one of them)'), explains layout options ('front_back' default or 'r10'), and introduces the 2048px minimum requirement. However, it creates a mild inconsistency by saying 'front OR session_id' while the schema marks front as required, which could confuse an agent relying on schema. Still, the description provides substantial value beyond 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?

The description opens with a specific verb+resource: 'Send one of the designer's own artworks for moderation.' It clearly distinguishes this from sibling tools like designer_uploads (which likely handles file uploads) and studio_generate (which creates sessions), by framing the action as submitting for moderation and accepting either artwork files or a finished studio session.

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 explicitly delineates two usage paths: provide artwork files (URL/upload_id) or provide a FINISHED Studio session_id from studio_generate. It also states that fetching the print is done server-side ('no need to download the print'), and includes an important caveat about moderation timing: 'catalog listing follows production and is not instant.' This gives clear when-to-use context and differentiates from alternatives.

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