designforyou

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

Annotations already indicate this is a non-read action and non-destructive, but the description adds key behavioral details: the tool is billed, and it is asynchronous because it returns an audition_id immediately and requires polling of audition_status until ready. These are important traits not captured by the annotations alone, enhancing transparency beyond the structured data.

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 three declarative sentences, each with a distinct purpose: define the action, explain the async flow and return artifacts, and indicate where the actor_id comes from. It is front-loaded with the primary verb and noun, contains no filler, and every sentence earns its place by contributing essential operational or prerequisite 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?

Despite having no output schema, the description explicitly discloses that the tool returns an audition_id immediately and later provides a shareable video_url, covering the return value lifecycle. It also flags billing, which is critical for a paid action. While it doesn't mention failure modes or alternate casting_id paths, those are sufficiently explained in the schema, so the description covers the core transaction workflow.

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 schema has 100% description coverage, so the baseline is 3. The tool description itself only highlights 'cue' and 'actor_id' source, without adding new meaning to parameters such as casting_id, direction_notes, or batch_approved. Since the schema already documents all parameters sufficiently, the description's marginal contribution to parameter understanding is minimal, consistent with a 3.

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 the specific verb 'Start' and resource 'casting audition', and elaborates with a concrete summary: the actor performs a cue in a short vertical video. It distinguishes this from sibling tools like audition_status (which polls status) and revise_audition (which modifies) by focusing on the initiation action and the immediate billing implication.

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 provides clear context for when to use this tool: to begin an audition. It includes operational workflow guidance ('Returns audition_id immediately; poll audition_status...') and points to a prerequisite ('Get actor_id from casting_roster'), but it does not explicitly enumerate exclusion criteria or compare with alternative audit tools beyond the workflow implication. That fits 'clear context, no 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, covering safety. The description adds useful specifics: status values, the video_url field when ready, and that it's free to call. This goes beyond the annotations without contradicting 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?

A single, well-structured sentence that front-loads the purpose and includes key return details. No redundant words or 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?

For a simple read-only status tool with one parameter and no output schema, the description sufficiently covers behavior, return values, and usage context. No significant gaps.

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 schema already fully describes audition_id as 'Audition id returned by audition' (100% coverage). The description's mention of 'started with audition' aligns with this but adds no additional parameter semantics beyond what the schema states.

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?

Description clearly states the tool checks an audition's status (rendering/ready/failed) and provides the video_url when ready. This distinguishes it from sibling tools like 'audition' (which starts the process) and 'delete_audition' or 'revise_audition'.

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 phrase 'started with audition' clarifies that the tool applies to auditions initiated via the 'audition' tool, and 'Free to call' suggests no cost concern. It doesn't explicitly name alternatives but gives clear contextual timing for use.

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, so the agent knows it's a safe read operation. The description adds value by stating the return format: 'Returns template IDs, names, and previews.' However, it does not disclose other behavioral nuances like pagination, rate limits, or how previews are represented. This is adequate but not rich, so a mid-range score is appropriate.

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 two sentences long and front-loaded with the core purpose. The first sentence establishes the action, the second covers filtering and results. Every word serves a purpose; there is no fluff or redundancy. This is a model of conciseness.

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's simplicity (2 optional parameters, read-only, output schema present), the description provides sufficient context for an agent to decide when to invoke it. It covers purpose, optional filters, and return content. It could mention subcategory filtering explicitly, but the schema fills that gap. The description is complete enough for this low-complexity 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?

The input schema already provides descriptions for both parameters (category and subcategory) with examples, achieving 100% schema coverage. The description adds a minor detail by listing an additional category example 'living-panels' not present in the schema, but it does not explain subcategory usage. Since the schema fully documents the parameters, a baseline score of 3 is 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?

The description clearly states the tool's purpose: 'Browse the DesignForYou template catalog.' It specifies the verb 'browse' and the resource 'template catalog', and distinguishes itself from sibling tools like create_template and recommend_template by focusing on browsing existing templates. It also mentions optional filtering and return values, making 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?

The description provides clear context for when to use this tool: browsing the template catalog with optional category/subcategory filters. It does not explicitly mention alternatives or exclusion criteria, but the purpose is so distinct from siblings (e.g., create_template, recommend_template) that the intended usage is evident. Missing explicit 'when not to use' guidance prevents a perfect score.

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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the operation returns a casting_id that preserves identity and provenance across takes, and restricts input to seeded/private actors. This adds behavioral context about persistence without contradicting annotations.

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?

Single sentence with a front-loaded verb, clear object, and return value. No filler or redundant restatement of the tool name.

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 six-parameter mutation with no output schema, the description gives the core action and return value but omits preconditions, repeated-cast behavior, and meaning of optional fields like notes/source_url. Sibling delete_casting hints at lifecycle but the description itself leaves these gaps.

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 only 17% (only character_description has a description). The description does not explain notes, source_url, or the relationship/semantics of actor_id/story_id beyond 'seeded or private actor' and 'one story character', so it fails to compensate for the low 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?

Description uses specific verb 'Bind' with clear resources: 'seeded or private actor' to 'one story character'. It distinguishes from sibling tools like casting_roster (listing), delete_casting (removal), and audition by describing the act of assigning an actor to a character and returning a casting_id.

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 phrase 'Bind a seeded or private actor to one story character' implies the tool should be used when assigning such an actor to a character, and 'across takes' suggests persistence. However, no explicit when-to-use/not-use guidance or alternatives are mentioned.

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, but the description adds critical behavioral context: this is a public catalog with seeded actors, excludes user private actors, and returns specific fields (headshots, type, bio). This goes beyond the annotations and clarifies the tool's data scope and contents.

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 concise sentences front-load the core purpose, then provide exclusion criteria and a recommended workflow. Every sentence earns its place, with no fluff or repetition of schema/annotation data.

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 simple read-only listing tool, the description fully explains what the agent gets (public roster with headshots, type, bio), who it belongs to (public, no private actors), and how to proceed (call audition with actor_id). Even without an output schema, the expected return fields and usage flow are clear.

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 input schema has one optional parameter that is an empty object with no properties, effectively meaning no meaningful parameters. The description adds no parameter details, but none are needed since the schema fully defines the empty input. Per the rubric, 0 meaningful params baseline is 4, so this is 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?

The description starts with a specific verb+resource+scope: 'List only the public seeded LetMeActForYou casting roster with headshots, type, and bio.' It clearly distinguishes this from related tools by explicitly stating it never includes private actors, and points to my_actors for that, giving it unique purpose among siblings.

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?

Provides explicit usage guidance: 'Call this first, show the user the seed actors, then call audition with the chosen actor_id.' It also names the alternative tool for private actors ('authenticated users can retrieve those with my_actors'), telling the agent when not to use this tool.

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, covering the safe read nature. The description adds useful context about the brief contents and intended workflow, which goes beyond the annotations. No contradictions or hidden behaviors are apparent. Minor gaps like response format details are acceptable for a simple getter.

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 two sentences, front-loaded with the action and resource, then provides usage context. Every sentence contributes meaning. The term 'no-server-LLM' is slightly terse 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?

For a simple getter with one parameter, the description is complete. It lists the return contents (PanelScript instructions, schema, unit templates, success criteria) and gives usage context. Annotations cover the safety profile. No output schema exists, but the description sufficiently explains what is returned.

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% (single parameter 'premise' with a clear description). The main description does not add additional parameter semantics. Baseline 3 is appropriate because the schema fully documents the parameter.

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 uses the specific verb 'Return' and names the resource 'no-server-LLM Living Panels authoring brief' with enumerated contents (PanelScript instructions, schema, unit templates, success criteria). It clearly distinguishes from sibling tools by focusing on the authoring brief and referencing the follow-up tool comic_submit_design.

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 states when to use the tool: when the MCP client will do creative direction with its own model. It also connects to the next step (comic_submit_design). However, it does not explicitly say when not to use it or mention alternative tools like comic_revision_brief, so it falls short of a full 5.

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 valuable behavioral context by enumerating the returned data (stale-write hash, dirty-node contract) and framing the tool as a step in the revision workflow, complementing the read-only annotation without contradicting it.

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 two sentences with the return payload front-loaded and the usage context clearly stated. Every word is purposeful; there is no redundancy or unnecessary detail.

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?

This is a simple read-only tool with one parameter, and the description lists its output components (Story JSON, stale-write hash, allowed patch paths, dirty-node contract) while specifying the workflow position. Given the lack of an output schema, the description provides enough information for an agent to understand the tool's role and invoke it 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?

The input schema fully covers the single parameter comic_id with a clear description ('Comic id to revise.'). The tool description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline score 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?

The description uses a specific verb ('Return') and resource ('current Story JSON, stale-write hash, allowed patch paths, and dirty-node contract'), clearly defining the tool's scope. It also distinguishes this from the sibling comic_submit_revision by explicitly positioning it as the pre-submission brief for client-authored edits.

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 states when to use the tool ('when the client will decide the edit with its own model') and directs the agent to the follow-up call ('then call comic_submit_revision'). This provides clear contextual guidance, though it does not enumerate when not to use it or name alternative tools.

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, so the description's main contribution is the 'Free to call' note and the semantic meaning of the ready flag (whole comic live at reader_url). This adds useful behavioral context beyond the structured annotations without contradicting 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 description is a single, information-dense sentence. It front-loads the purpose, then details the metrics and the ready flag, with no wasted words or redundancy.

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 one-parameter tool with no output schema, the description fully explains what the tool returns (panels, motion clips, voice lines counts, ready flag) and the significance of ready=true. Combined with strong annotations, this is a complete picture for an agent.

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 the parameter comic_id described as 'Comic id returned by create_comic'. The description reuses this context but adds no new parameter-specific details, so it meets the baseline without exceeding 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?

The description clearly states the tool's function: checking asset-production progress for a comic. It specifies the resource (comic created with create_comic) and the exact metrics (panels, motion clips, voice lines done vs total, ready flag), distinguishing it from sibling tools like audition_status.

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 provides clear context for when to use the tool—after creating a comic with create_comic—and adds the 'Free to call' guideline. It does not explicitly mention alternatives or when-not-to-use, but the context is sufficient for a status-checking tool.

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?

Beyond annotations, the description discloses that the tool validates, saves, generates character sheets, panel/unit art, motion clips, voice-over, and assembles the public reader. This conveys significant side effects and mutation, consistent with readOnlyHint=false and destructiveHint=false. It does not mention costs or return values, but annotations already cover the safety profile.

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 a single, well-structured sentence that front-loads the purpose and then details the pipeline. Every clause adds actionable context, with no filler or redundancy.

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?

The description covers the input and processing pipeline comprehensively, but omits what the function returns or how the agent should follow up. Since there is no output schema, this return-value gap is a notable omission, though sibling tools like comic_status may imply monitoring.

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%, with all five parameters well-described in the input schema. The description does not add param-specific semantics beyond the overall workflow, so the baseline of 3 is 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?

The description clearly states the tool accepts a client-authored Living Panels Story JSON and starts artifact production, including the specific pipeline (validate, save, generate, assemble). It distinguishes itself from sibling tools like comic_submit_revision and create_comic by emphasizing client-directed input and avoiding the server story LLM.

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 provides clear context for when to use this tool: when the client authors the story directly, without relying on a server LLM. It implies a workflow but does not explicitly name alternatives or exclusions, making it helpful but not fully prescriptive.

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?

The description discloses a key behavioral trait: it does not invoke a server revision LLM, and it regenerates only inferred dirty producer nodes (e.g., panel:<id>, motion:<id>, tts:<bubble_id>). This adds meaningful context beyond the readOnlyHint=false and destructiveHint=false annotations, which are consistent with the described write-and-regenerate behavior.

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 sentences, front-loaded with the primary action, and every clause contributes to understanding purpose and behavior. No redundancy or 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?

The description, combined with a 100% schema-covered parameter list and clear annotations, is sufficient for an agent to select and invoke the tool. It could mention return values or status, but since there is no output schema, the description covers the core behavior adequately without major gaps.

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 the baseline is 3. The description adds value by giving concrete examples of dirty producer nodes and explaining that targeted changes regenerate only those nodes, reinforcing the distinction between the 'changes' and 'story' parameters. This goes beyond the schema alone.

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 uses a specific verb ('Apply') and names the exact resource ('client-authored Living Panels revision'), while the qualifier 'without using a server revision LLM' distinguishes it from server-driven revision workflows. This clearly separates it from siblings like comic_revision_brief or comic_submit_design.

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 clear context: use this tool when applying a client-authored revision, not a server LLM revision. It also notes that targeted changes are the preferred path for small edits. It doesn't explicitly name alternative tools, but the guidance is sufficient for an agent to decide when to invoke it.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the disclosure adds significant behavioral context: generation of headshot, S3 storage, draft privacy, clip prioritization of performance_reference_url, and default template quality. This exceeds what annotations provide, though it doesn't cover all possible side effects like rate limits.

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 four sentences, each delivering distinct information: core purpose, draft/public workflow, performance reference guidance, and template/visual description guidance. It is front-loaded with the main purpose and contains zero wasted words.

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?

The description covers the creation flow, return value, draft state, publishing path, and key parameter guidance. It doesn't explain every minor parameter (bio, emoji, actor_type) but these are likely self-explanatory. Overall, it provides sufficient context for an agent to understand the tool's role and usage.

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 description adds valuable meaning to visual_description (stable physical identity, not performance direction) and performance_reference_url (full-body standing, prioritized). However, with schema coverage at only 43%, parameters like bio, emoji, and actor_type are left undocumented in both the schema and description, so the description doesn't fully compensate for the gap.

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 the tool creates a private LetMeActForYou actor draft, generates a casting headshot, stores it on S3, and returns actor_id for cast_character or audition. This specific verb+resource+outcome clearly distinguishes it from siblings like publish_actor and cast_character.

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 explains the draft workflow, noting that drafts never appear in the public feed and that publish_actor is used when the actor is ready. It also gives guidance on providing performance_reference_url when available. However, it doesn't explicitly name alternative creation tools or directly state 'use this instead of X', but the context 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?

The description goes far beyond annotations by revealing asynchronous behavior: 'starts generating every asset in the background,' 'Returns immediately,' and 'Production takes several minutes — poll comic_status.' It also discloses the output (story summary, reader_url) and the need for polling. No contradiction with annotations (readOnlyHint=false, openWorldHint=true, 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?

The description is four sentences, front-loaded with the main verb and resource, and every sentence adds unique value: scope, background generation, immediate return, and follow-up polling. No fluff or redundancy.

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?

Despite no output schema, the description gives a complete picture of the tool's behavior and result: what is created, what is returned, how long it takes, and how to check status. It even mentions details like '~13 panels of art with character consistency' and 'per-line voice-over,' making it fully self-contained for a complex creation 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% for the single parameter 'premise,' and the schema already explains it as 'The story premise, one paragraph is plenty.' The description only repeats 'one-paragraph premise' without adding new meaning about parameter formatting or constraints. Baseline 3 is appropriate since the schema handles 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?

The description clearly states the tool's function: 'Write and produce a Living Panels interactive comic from a one-paragraph premise.' It details the full scope (5-page comic, panels, dialogue, motion, voice casting) and distinguishes it from lower-level tools in the sibling list (e.g., cast_character, generate_scene_frame) by emphasizing it's a single all-in-one call.

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 implies when to use the tool (for creating a full comic from a premise) and provides a workflow ('Returns immediately... poll comic_status until ready... share the reader_url'). However, it does not explicitly contrast with alternatives like comic_revision_brief or comic_design_brief, so it lacks a clear 'when-not-to-use' statement.

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 mark this as non-read-only and non-destructive; the description adds meaningful context: it stores a user-owned template in the canonical catalog, does not publish to the anonymous gallery, and the returned id is immediately usable with other tools. This goes beyond the annotations by clarifying side effects and integration behavior.

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 sentences, 46 words, with the action and resource front-loaded. Every clause adds value—what it creates, how the result is used, where it is stored, and what it does not do.

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?

The tool has 10 parameters and no output schema, but the description covers the essential return behavior (template_id) and its integration with get_text_fields and generate. It does not enumerate all parameters, but the schema already handles that. The description is sufficient for the agent to select and invoke the tool 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?

Schema coverage is 100%, so the baseline is 3. The description adds little parameter-specific detail beyond calling it a 'structured brief', but the schema already thoroughly documents each parameter, so no significant gap exists.

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 starts with a specific verb ('Create') and resource ('private reusable DesignForYou template') and clearly states it derives from a structured brief. It distinguishes itself from siblings like browse_templates and generate by emphasizing privacy, reusability, and catalog storage.

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 explains that the returned template_id works with get_text_fields and generate, and explicitly states it does not publish to the anonymous gallery, giving the agent a clear sense of when this tool is appropriate. It lacks an explicit alternative name, so it doesn't fully earn a 5, but the context is strong.

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 mark the tool as destructive (destructiveHint=true), but the description adds valuable behavioral details beyond that: it also deletes the headshot, refuses certain actor types, and notes it is 'free'. These are non-obvious traits that help the agent anticipate outcomes.

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 two concise sentences, front-loaded with the action and followed by constraints. Every word earns its place, and it avoids redundancy with the annotations.

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 simple one-parameter destructive tool, the description is complete: it explains the scope (unused private actor), the side effect (headshot deletion), and the refusal conditions. No output schema exists, but the tool's behavior is sufficiently covered.

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 schema description coverage at 0%, the description carries the burden for explaining actor_id. It implicitly defines it as the identifier of the actor to delete by saying 'Delete an unused private actor...', but does not explicitly label the parameter or elaborate on its constraints beyond what the schema already provides. This is adequate but not rich.

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 ('Delete') with a specific resource ('an unused private actor and headshot'). It also distinguishes the scope (private, unused) and mentions refusal conditions, which differentiates it from sibling tools like create_actor or my_actors.

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 provides clear context for when to use the tool: it targets unused private actors and explains it will refuse seeded actors or those referenced by active castings/auditions. This gives implicit guidance on when the tool is appropriate, though it doesn't explicitly name alternative tools for other cases.

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?

Discloses that deletion is permanent, that a minimal tombstone is retained for billing and audit, and that the operation is destructive and free. This goes beyond the destructiveHint annotation by explaining the tombstone side effect and the scope (authenticated user's own media), enhancing transparency without contradicting annotations.

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 sentences with no fluff; each clause adds relevant information: what is deleted, when it applies, what is kept, and the cost implication. Highly efficient and front-loaded, with no redundant phrasing.

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 simple destructive tool with one parameter and no output schema, the description covers core behavior, eligible states, and side effects. It lacks explicit return value documentation, but without an output schema this is not critical. It is sufficiently complete for an agent to 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?

The input schema has one required parameter, audition_id, with no schema description (0% coverage). The description references 'one ... audition' but does not explicitly state that audition_id identifies the target, nor does it mention any format or validation expectations. The parameter name is self-explanatory, but the description fails to compensate for the lack of schema documentation.

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?

Clearly states the tool permanently removes the authenticated user's media and direction for a specific audition, with eligibility limited to ready or refunded-failed states. This distinguishes it from sibling tools like revise_audition or delete_actor by specifying the action, target, and conditions.

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 provides clear context that only ready or refunded-failed auditions are eligible, which implicitly excludes other states. It does not explicitly name alternative tools, but the state restriction serves as a usage boundary and gives the agent enough guidance to select this tool appropriately.

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?

Beyond the annotations (destructiveHint=true), the description adds 'free' (no cost) and the refusal behavior when active auditions reference it. These are useful behavioral traits not captured in the structured data.

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 adding meaningful information. The description is front-loaded with the core action and avoids any 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?

For a one-parameter delete tool without an output schema, the description covers the essential purpose, a condition, and a cost note. It does not mention return values, but that is unnecessary given the tool's simplicity and the absence of an output schema.

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 0% schema description coverage, the description should compensate, but it only refers to 'casting' without explicitly detailing the casting_id parameter. The schema already provides the title 'Casting Id' and length constraints, so the description adds minimal extra meaning.

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 the verb ('Delete') and resource ('casting'), with a specific scope ('unused authenticated-user casting'). It also distinguishes itself from sibling tools like delete_actor and delete_audition by focusing on castings and includes a key condition ('Refuses while active auditions reference it').

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 provides an explicit when-not condition: the tool refuses to delete while active auditions reference the casting. This tells the agent when the tool will fail and implies it should only be used for unused castings, serving as clear usage guidance.

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?

The description discloses behavioral traits beyond annotations: it explains that session_id triggers refinement (editing previous image), context_ids provide visual context for consistency, and model selection with H3 aliases. It details how context_labels work for multi-reference models, and skip_prompt_merge bypasses compression. Annotations already show write intent (readOnlyHint=false) and non-destructive nature (destructiveHint=false), so the description adds rich operational context without contradiction.

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 three sentences with no wasted words. It front-loads the main purpose and then efficiently covers all major parameters and usage patterns. Every sentence earns its place by explaining a core aspect of the tool's behavior.

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 12 parameters and 100% schema coverage, the description provides a thorough workflow overview. It explains the required parameters, optional refinements, and model options. It could clarify the relationship between context_ids and reference_urls (are they mutually exclusive?) and note that context_labels only applies to gpt-image-2. However, it covers the core use cases well and the output schema exists to document return values.

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 baseline is 3. The description adds significant semantic context: explains that variants support expressions/time-of-day, context_ids ensure character consistency, and skip_prompt_merge retains detail for complex scenes. It also clarifies model aliases ('h3 balanced' == 'minimax-h3-image-balanced'). This goes beyond the schema's descriptions and helps the agent understand parameter interactions.

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 the verb 'generate' and the resource 'finished images from a template plus a description'. It distinguishes itself from sibling tools like recommend_template by explicitly stating the prerequisite of having a template_id, differentiating it from other generation tools. It covers a wide range of use cases across categories (Instagram, logo, etc.).

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?

Provides explicit guidance: 'Use this after the user has selected or explicitly supplied a template_id; otherwise call recommend_template first'. Also explains when to use variants, session_id, context_ids, skip_prompt_merge, and model aliases. This directly helps the agent decide between this tool and its siblings.

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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses important runtime behaviors: headshots are used as identity references, the output is a stored image_url, default provider is Gemini, Grok caps at 3 actor references, and continuity_scene_frame_id preserves set/props/lighting but NOT pose/composition. No contradiction with annotations.

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?

Six sentences, each earning its place: purpose, continuity workflow, actor filtering, composition reference, provider default, and timing use-case. It is front-loaded and reads naturally without redundancy.

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 an 11-parameter tool with no output schema, the description covers the essential operational context: what the tool returns (image_url), how to chain for continuity, how to preserve previs composition, and when to choose providers. The absence of an output schema is mitigated by mentioning the stored image_url return.

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 baseline is 3, but the description adds high-value semantics: continuity_scene_frame_id resets pose/composition, composition_reference_url preserves previs camera/blocking, and actor_ids should be limited to visible actors. It clarifies that pose/composition parameters are reused per shot.

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 begins with a specific verb and resource: 'Generate one actor-grounded narrative first frame' from actor_ids plus location, wardrobe, pose, and composition. It also distinguishes itself from adjacent tools by stating 'Use this before animation when a close-up headshot is not enough,' clearly separating it from animation and character-video siblings.

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 workflow guidance is provided: 'For multi-shot continuity, first generate a wide scene reference, then pass its scene_frame_id...' and 'Pass only the actor_ids that should be visible in that shot.' It also explains when to use composition_reference_url and recommends provider switching via 'pass provider='grok''. The closing line gives a concrete alternative-use context against existing animation tools.

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 mark readOnlyHint=true, so the read-only nature is known. The description adds value by specifying the authenticated-user requirement, the exact data returned (balance, usage, Stripe status), and that it is free to call. No contradictions with annotations.

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 a single sentence, front-loaded with the verb and resource, and contains no filler. Every word adds meaning, earning a high score.

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 there are no parameters and no output schema, the description is sufficiently complete for a simple read-only balance check. It clearly lists what the user gets. It could mention response format, but that is not essential for such a straightforward 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?

The tool has zero parameters, and schema description coverage is 100%. With no parameters, the baseline is 4, and the description correctly focuses on the return value rather than explaining non-existent 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 the tool's function with a specific verb 'Return' and the exact resource: 'the authenticated user's current credit balance, usage, and Stripe subscription status.' It fully distinguishes from siblings, none of which relate to credits.

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 implies when to use it (checking credits) and adds 'Free to call' as a usage hint. However, it does not explicitly mention alternatives or exclusions. Since no sibling tools cover this functionality, the lack of explicit alternatives is acceptable.

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 read-only nature is covered. The description adds behavioral context by stating the operation is free and that it returns current values of editable fields, which provides useful information beyond the annotations without contradicting 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 description is two sentences long and every word adds value. The first sentence states the function, and the second provides precise usage guidance without any redundancy or 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?

For a simple read-only listing tool with one parameter and no output schema, the description is complete: it explains what is returned (current values of editable text fields), when to use it, and how it relates to the generate tool. No further information is needed for an agent to select and invoke it 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?

The input schema has full coverage (100%) for the single parameter template_id, with a description already stating 'The template ID to get text fields for.' The tool description does not add further semantic detail about the parameter, so the baseline of 3 applies since the schema handles the meaning adequately.

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 the tool lists a template's editable text fields (headline, subhead, CTA, etc.) with current values. The verb 'list' and specific resource 'template text fields' make the purpose unambiguous, and it distinguishes itself from sibling tools like generate by explicitly positioning itself as a pre-generation step.

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 says to use it right after a template is chosen and BEFORE generate when precise field filling is desired instead of a freeform description. This provides clear when-to-use guidance and contrasts with the alternative, making the usage context unmistakable.

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?

No annotations are provided, so the description carries the full burden, and it delivers: it discloses that the tool is free, supports bounded offset pagination, returns newest first, and explicitly states what it never returns (internal identity prompts or visual descriptions). This is rich behavioral context beyond 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?

The description is a single, dense sentence that packs purpose, scope, ordering, cost, pagination, and exclusions without wasted words. Every clause contributes meaningful 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?

For a simple list tool with no output schema, the description covers the essential aspects: what it lists, whose, order, cost, pagination, and exclusions. It doesn't detail the response fields, but this is a minor gap given the tool's simplicity and the presence of pagination parameters.

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 defines limit and offset clearly. The description adds value by stating 'bounded offset pagination', which clarifies the pagination behavior and implies that offset has limits. This enriches the parameter semantics beyond the raw 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 uses a specific verb 'List' and resource 'private reusable LetMeActForYou actors' with explicit scope 'authenticated user's' and sorting 'newest first'. This clearly distinguishes it from sibling tools like create_actor or my_auditions by focusing on private list functionality.

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 context is clear: this tool lists only the authenticated user's private reusable actors, implying it should be used when that specific scope is needed. It does not explicitly name alternative tools, but the 'only' and 'private reusable' wording provide implicit usage boundaries without 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?

No annotations are provided, so the description carries the burden. It discloses key behaviors (list only authenticated user's history, newest first, free, pagination, status filter) but does not mention potential rate limits, error conditions, or the exact response structure. It adds useful context beyond a minimal description, but not exhaustive.

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 two sentences, front-loaded with the primary purpose, and every word earns its place. 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?

For a list tool with three optional parameters and no output schema, the description covers purpose, scope, ordering, cost, pagination, and filtering. It lacks explicit return type details, but this is a minor gap given the simplicity of the 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 the schema fully documents all three parameters. The description adds concise confirmation of pagination ('bounded offset pagination') and the status filter's allowed values, but does not add substantially 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 uses a specific verb ('List'), names the resource ('audition history'), scopes it to 'the authenticated user's', and specifies ordering ('newest first'), clearly distinguishing it from sibling tools like audition_status or delete_audition.

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?

While the description clearly indicates the tool is for listing the user's audition history, it does not explicitly mention alternatives or provide when-not-to-use guidance. Sibling tools such as audition_status and revise_audition are not referenced, leaving usage context implied rather than explicit.

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 provide readOnlyHint false, destructiveHint false, and openWorldHint false. The description adds useful context about caller permissions and privacy of auditions, but it does not disclose important behavioral traits such as reversibility, what happens to the draft after publishing, or the output/return value. Since annotations are minimal, the description carries a larger burden and only partially meets it.

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 concise (3 sentences) and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds relevant context (permissions, privacy). No wasted words or redundancy.

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?

The purpose is clear, but the description lacks outcome details (e.g., what the response contains, whether publishing is reversible, how the public roster is affected). Since there is no output schema, the description should compensate by explaining the result of the operation, which it does not. It also omits explicit prerequisites beyond 'approved' video, though these are implied.

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 the schema already fully documents each parameter. The description's phrase 'approved seamless idle-loop video' mirrors the schema's 'approved seamless idle-loop MP4', adding no material semantic value. Baseline 3 is appropriate because the schema does the heavy lifting.

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 the action: 'Promote an operator-owned actor draft into the shared public LetMeActForYou roster and bind its approved seamless idle-loop video.' This is specific, uses a strong verb ('promote'), identifies the resource (actor draft), and differentiates from sibling tools like create_actor or delete_actor.

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 provides clear context for when this tool is appropriate: publishing a draft to the public roster. It also gives an explicit authorization constraint ('Only configured public actor publishers and first-party internal services can call this tool') and a privacy nuance ('Auditions remain private'). However, it does not explicitly name alternative tools or state 'use this instead of X', so it stops short of a 5.

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?

Beyond the readOnlyHint annotation, the description discloses key behaviors: auto-detecting category, ranking by relevance, returning recommendations for user selection, and the exact condition to call generate. This adds meaningful context not present in annotations.

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 sentences, front-loaded with the main verb and resource, and every clause serves a purpose: purpose, workflow, and explicit guardrail. No fluff or redundancy.

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 output schema and complete parameter descriptions, the description fully covers the tool's purpose, usage flow, and key constraints. It is sufficient for the agent to select and invoke correctly without additional context.

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 input schema already covers all parameters with descriptions (100% coverage), including auto-detection for category. The description adds only a general 'Describe what you need' which overlaps with the use_case parameter. Minimal added semantic value beyond 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 and resource: 'Recommend the best matching templates for any use case.' It clearly distinguishes from siblings like browse_templates (generic browsing) and generate (template generation) by focusing on auto-detection and relevance ranking.

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?

Provides explicit when-to-use guidance ('any use case') and an explicit exclusion: 'do not call generate in the same turn unless the user explicitly names a template_id or asks you to skip selection.' This is concrete, actionable direction for the agent.

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 indicate this is a write operation (readOnlyHint=false) and not destructive. The description goes further by disclosing that it is free, stores only bounded triage metadata, and does not copy prompts, media URLs, billing data, or account identity. This is rich behavioral context beyond the annotations.

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 two sentences, front-loaded with the primary purpose, followed by cost and privacy details. Every sentence adds value with no redundancy or fluff.

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 report submission tool with no output schema, the description covers the essential aspects: what can be reported, target ownership/visibility, cost, and data handling. It does not describe the response or confirmation behavior, but this is acceptable given the simplicity of the operation and lack of output schema.

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 0%, so the description must compensate. It does clarify target_type semantics by specifying that actors must be visible and auditions must be owned by the user, which gives meaning to target_id and target_type. However, it does not explain the reason enum values or the details field, so parameter understanding is only partially addressed.

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 the action ('Report') and the specific resources: a visible actor or an audition owned by the authenticated user. It also introduces important scope constraints (visibility and ownership) that distinguish this tool from any sibling, and no other reporting tools exist.

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 provides clear context for when to use the tool: to report a visible actor or an audition the user owns. It does not explicitly mention alternatives or exclusions, but since there are no sibling reporting tools, this is sufficient. The ownership/visibility condition effectively guides usage.

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?

The description discloses important behavioral details beyond the annotations: it inherits actor, story casting, cue, emotion, and line unless overrides are supplied, and preserves parent/root ids and the director note. This adds context about data flow and side effects. The annotations (readOnlyHint=false, destructiveHint=false) align with the create operation, and there is no contradiction.

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 compact and information-dense, consisting of two sentences that front-load the primary action ('Create a child take') and then efficiently list inheritance and preservation behavior. Every clause adds value without redundancy.

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 create-type tool with no output schema, the description sufficiently covers the essential behavior: what is created, what is inherited, and what is preserved. It does not explain the return value or potential side effects, but the annotations and schema fill in some gaps. Overall, it is complete enough for an agent to decide when and how to invoke the 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?

With schema description coverage only at 17%, the description partially compensates by explaining that optional parameters (cue, emotion, line) serve as overrides and that parent/root ids are preserved. However, it does not clarify the role of direction_notes (whether it is inherited or new) or fully explain the relationship between parent_audition_id and the created child take. The description adds some meaning but leaves gaps.

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 the action: 'Create a child take from an existing audition.' This uses a specific verb and resource, and the phrase 'from an existing audition' distinguishes it from sibling tools like 'audition' (creating a new audition) and 'delete_audition'. The purpose is unambiguous and immediately actionable.

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 provides clear context for when to use the tool: whenever a new take based on an existing audition is needed. It does not explicitly mention alternatives or when not to use it, but the context is strong enough for an agent to infer the appropriate situation. Lack of explicit exclusions prevents a 5.

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 are minimal (readOnly=false, destructive=false, openWorld=true), so the description carries the transparency burden. It discloses credit costs (base 3, +2 per hi-res cell), the background-removal behavior, the fixed-grid cropping, and the cell-resolution limitation that hi_res_cells addresses. This goes far beyond the structured annotations.

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 dense and front-loaded: the first sentence captures the full pipeline, and the optional hi-res details are placed after the base behavior. No filler or repeated schema information; every sentence adds material context like credits, resolution limits, or model override behavior.

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's complexity (8 parameters, nested objects, output schema), the description is remarkably complete. It explains the main workflow, costs, optional hi-res enhancement, and model routing. Because an output schema exists, the absence of return-value details is acceptable.

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 only 25%, so the description must compensate. It does add significant meaning for quality.hi_res_cells and quality.hi_res_model by explaining costs, purpose, and model routing, but it leaves most other core parameters (character, style, sheet, cells, output, provider) to the schema. The schema's nested titles and defaults help, but the description only partially fills the gap.

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 uses a specific verb ('Generate') plus resource ('visual-novel character sprite sheet') and enumerates the exact pipeline steps: crop, chroma-key removal, validation, and manifest output. It clearly distinguishes this tool from siblings like generate_character_video or generate_scene_frame by scoping it to VN sprite sheets.

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 clear context for when to use the tool: to produce a VN Creator-ready sprite sheet with fixed-grid cropping and background removal. It does not explicitly name alternatives or exclusion criteria, but the specificity and billing details make the intended use 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?

The annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds valuable behavioral context: 'no-cost,' 'does not generate images, use an LLM, or charge credits,' and 'fixed' payload. This goes beyond the annotations to clarify side-effect-free behavior and tool limitations, though it doesn't detail the return payload shape (but output schema exists).

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 two sentences, front-loaded with the core purpose, and every clause earns its place. It is concise without being under-specified.

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 simple tool with one optional parameter, existing output schema, and clear annotations, the description fully covers the context: what it does, when to use it, what it avoids, and its cost behavior. No additional context is needed to use it 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?

Schema coverage is 100% and the parameter 'mode' has a clear description ('Which widget payload shape to return without generation') and a pattern defining allowed values. The description adds little extra meaning beyond the schema, just emphasizing 'fixed' and the debugging context. Baseline 3 is appropriate since schema does the heavy lifting.

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 the tool's purpose: 'Return a fixed, no-cost DesignForYou widget payload for ChatGPT Apps debugging.' It specifies the verb (return), resource (widget payload), and purpose (debugging). It also distinguishes itself from siblings by explicitly noting it 'does not generate images, use an LLM, or charge credits.'

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 explicit when-to-use guidance: 'Use this only to verify the template gallery/result iframe renders correctly.' It also provides exclusions by stating what it does NOT do (generate images, use an LLM, charge credits), effectively telling the agent when not to use it and implying alternatives.

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