Cannon Studio

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

The description discloses that it 'may update key/token usage metadata' but does not spend credits, enqueue jobs, change assets, or expose secrets. This adds behavioral context beyond the annotations, which only indicate readOnlyHint=false. The side effect is noted, though the exact nature of 'usage metadata' is somewhat vague, so a slightly lower score is warranted.

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 directly followed by essential context about prerequisites and non-effects. Every sentence contributes value, with no fluff 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 zero-parameter tool with an output schema, the description covers the core purpose, when to use it, required authentication, side effects, and what it does not do. This is complete given the tool's simplicity and the presence 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?

The tool has zero parameters, and the input schema is empty. The description correctly does not attempt to add parameter information, and the schema coverage is 100% by definition. Baseline score of 4 applies since no compensation is needed.

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 ('check') and resource ('authenticated Cannon Studio account/API connectivity'), clearly stating what the tool does. It distinguishes itself from sibling tools by specifying it is for use 'before estimating or creating requests,' which sets it apart from estimation and creation tools.

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 indicates when to use the tool ('before estimating or creating requests') and states the prerequisite (OAuth or developer API key). This provides clear context and implicitly excludes use cases where authentication is not needed or where the user is already past the connectivity-check stage.

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 read-only, idempotent, and non-destructive. The description adds valuable context: no auth, no state changes, no charges, returns approved positioning, and explicitly warns agents not to invent competitor claims. This goes well beyond the annotations and helps prevent misuse.

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. The first states the core purpose, and the second adds key safety and operational context. No redundant wording 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 tool is well-supported by a rich schema, output schema, and annotations. The description covers the essential behavioral caveat (don't invent competitor claims) and operational traits (no auth, no charges). Given the output schema exists, return format details are unnecessary, and nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters have detailed descriptions in the schema, so the schema coverage is 100%. The description references 'named alternatives' and 'use case' but does not add new parameter syntax or format details. Baseline 3 is appropriate since the schema carries the parameter burden.

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 compares Cannon Studio's fit against named alternatives for a use case. This is a specific verb ('compare') with a clear resource and scope, distinguishing it from sibling tools like recommend_workflow or search.

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 usage when a user asks for a comparison against specific competitor tools for a job-to-be-done. It does not explicitly exclude other scenarios or reference sibling tools, but the 'for a use case' phrasing provides clear context, and the caution not to invent competitor claims gives important behavioral 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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds real behavioral value beyond them: draft-only records and no credit spend, plus the auto-created scene/shot and implicit world creation. It does not mention that repeat calls (idempotentHint=false) produce duplicates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with zero filler; the create action is front-loaded and the side-effect caveat follows immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should tell the agent what it gets back (e.g. a project id usable with get_creator_flow_project or update_creator_flow_project), and it should cover the remaining parameters. It covers structure and side effects but leaves those 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 coverage is only 25%, so the description must compensate, but it only re-explains world_id (already described in the schema) and ignores title, summary, and aspect_ratio (including its 16:9 default and enum). Most parameter meaning remains undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (create a blank Creator Flow project) and even specifies the resulting structure: one scene and one shot. It implicitly separates itself from create_generation_request and estimate_generation_cost by stating no generation or credit spend occurs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It documents the world_id conditional (omit to create a new world), which is usage-relevant, but never says when to use this tool versus create_world or create_generation_request, nor states prerequisites. Usage is implied rather than spelled out.

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?

Despite annotations indicating destructive/non-idempotent behavior, the description adds valuable context: it can spend credits up to max_credits, is irreversible after submission, and requires explicit user approval. It clarifies what it does not do, mitigating the destructiveHint's broad implication. 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?

The description is three efficient sentences: purpose, requirements/risks, and workflow/exclusions. Every sentence adds value, and the most important information (explicit approval, billable, cancellation) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 6 parameters, nested input objects, and an output schema, the description covers the critical operational context: approval workflow, credit limits, authentication, non-cancellation, and what it does not do. Combined with the rich schema and annotations, it is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the meaning of 'confirmed' and 'max_credits' but does not add new parameter-level detail beyond what the schema already provides.

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 'Create billable async Cannon Studio generation work only after explicit user approval,' which uses a specific verb (Create), resource (Cannon Studio generation request), and a clear condition. This distinguishes it from sibling tools like estimate_generation_cost or get_generation_request.

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: 'Use estimate_generation_cost first, then set confirmed=true and a user-approved max_credits cap.' It also states prerequisites (OAuth or developer API key), exclusions (does not create API keys, charge payments, or delete assets), and a critical caveat that requests cannot be cancelled through MCP after submission.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false. The description adds one genuinely useful behavioral fact beyond annotations: no credit spend and no media generation. But it omits what happens on duplicate titles, what is returned, or whether the world is immediately visible to other tools like get_world.

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 compact sentences, front-loaded with the action and field list, followed by the key constraint. No filler text, though the field enumeration is somewhat redundant with the schema.

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 7-parameter mutation tool with no output schema and 0% schema coverage, the description is only marginally adequate. It flags no-credit-spend, which is valuable, but leaves field semantics, arrays, and the 'owned' concept unexplained.

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% across 7 parameters, so the description must compensate. It names six of the seven fields but provides no semantics: it does not explain that 'theme' aliases 'description', that lists are capped at 50 items, or what a 'video production cue' should contain. The schema lists property names only; the description largely repeats them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create an owned world') and enumerates the content fields it accepts (title, description, genre, visual style, lore, production cues). It distinguishes itself from siblings like create_world_asset and update_world, though 'owned' is never explained.

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 clause 'No media generation or credit spend' implies when this is the right tool (setup before asset generation) but does not explicitly name alternatives such as create_generation_request or estimate_generation_cost. Usage is implied rather than stated.

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 declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the mutation profile is partly covered. The description adds real value by clarifying that the tool is metadata-only, does not download media, and spends no credits, which would otherwise be a serious ambiguity for a create tool on a paid platform. It doesn't state ownership/auth requirements or what happens on duplicate name.

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 tight sentences, front-loaded with the verb and resource, then immediately disambiguating with the crucially negative 'does not generate or download media and spends no credits.' No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 10 params at 0% schema coverage and no output schema, the description is too thin to be complete. It clarifies cost/behavior but not parameter meaning, return shape, or authentication. It covers the highest-value ambiguity (credits/media) but leaves the schema without compensating documentation.

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% across 10 parameters, so the description must carry the load. It only loosely gestures at 'descriptive fields' and 'optional existing HTTPS media references,' leaving notes, summary, imagePromptAddon, videoPromptAddon, world_id, referenceImages, and imageUrl entire meanings undocumented. That is a substantial gap for a tool with 10 params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Create) and resource (world asset) and enumerates the six kinds it supports, which maps precisely to the schema enum. It also distinguishes itself from generation siblings by defining itself as metadata-only.

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 says it does not generate or download media and spends no credits, implicitly routing media generation to create_generation_request, but it never names that sibling or states when to use this tool versus fetching/updating an asset. Usage context is 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 declare destructiveHint=true and non-idempotent, but the description adds critical behavior beyond them: the preview-first default, the owner-only authorization requirement, and precisely what is destroyed (story/collaboration records) versus preserved (world/library assets). This is exactly the kind of destructive-scope detail an agent needs.

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 tightly packed sentences with the default behavior front-loaded, then the constraint, then the escalation path. Every sentence carries load-bearing information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with no output schema, the description covers the safety profile, authorization, destruction scope, and the confirmation workflow. An agent has everything needed to invoke it correctly and safely.

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 each parameter is already documented, setting a baseline of 3. The description adds workflow-level meaning by specifying the sequencing and the requirement that expected_title come from the preview, which the schema field alone states more narrowly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Delete') and resource ('Creator Flow Project'), and immediately scopes it as a preview-by-default, owner-only operation. This clearly distinguishes it from sibling deletes like delete_world and delete_world_asset by naming the record types affected (story/collaboration) and preserved (world/library assets).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit two-step protocol: keep dry_run=true until the user approves the stated impact, then set dry_run=false, confirmed=true, and expected_title from the preview. It names the exact conditions and parameter states that gate the dangerous call, leaving nothing to inference.

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

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

Annotations already flag destructiveHint=true, so the safety profile is known, but the description goes further: it discloses the preview-by-default behavior, the approval gate, and precisely what is destroyed (projects, stories, relationships) versus what is merely detached (reusable assets). That distinction matters for an irreversible operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the preview behavior and followed by the action contract. No filler; the slightly non-essential clause about the deletion service is the only marginal weight.

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 destructive tool with no output schema, the description covers impact scope, the preview/confirm sequence, and the guard parameters. Nothing an agent needs to avoid an accidental destructive call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so individual parameter meanings are already documented, setting the baseline at 3. The description adds value beyond the schema by tying the three safety parameters together as a single post-approval gesture, clarifying they are supplied jointly rather than independently.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (delete world) and enumerates the affected entities (projects/stories/relationships) versus detached reusable assets. This clearly separates it from siblings like delete_world_asset and delete_creator_flow_project, which target narrower resources.

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?

Prescribes an explicit two-phase workflow: preview first, obtain explicit user approval, then re-invoke with dry_run=false, confirmed=true, expected_title. The trigger condition and required ordering are stated rather than left to inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds important context beyond annotations: a preview-first workflow, explicit user approval requirement, and that existing projects may lose references to the deleted asset.

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 compact sentences with zero waste. It front-loads the preview requirement and then the approval-gated parameters, which is exactly the needed order for an agent.

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 destructive tool with no output schema, the description covers preview, approval gating, and reference-loss risk. It omits any explanation of the world_id parameter or the kind enum, but annotations already cover the destructive nature and the critical safety workflow is present.

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 50%, and the description reinforces dry_run, confirmed, and expected_title with workflow semantics. However, it leaves asset_id, kind, and world_id without any description or usage clarification, so it only partially compensates for the coverage 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 ('Preview') and resource ('owned library asset deletion'), and the deletion itself is clearly implied by the tool name. It does not explicitly name a sibling alternative, but the 'owned library asset' scope distinguishes it from delete_world.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear conditional guidance: preview by default, and only after explicit approval set dry_run=false, confirmed=true, and expected_title. It does not list sibling alternatives or when-not-to-use cases, but the approval workflow is practical 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?

All annotations are false and minimally informative; the description compensates by disclosing the non-obvious side effect ('may update key/token usage metadata') and enumerating non-actions (no credit spend, no job enqueue, no asset changes). No contradiction with annotations. This goes beyond the structured data and provides meaningful behavioral context.

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 dense sentences with no filler. It front-loads the core purpose, then side effects and workflow; every clause carries information relevant to safe use.

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 nested input and output schema, but the description covers purpose, auth, side effects, and integration with two sibling tools. It does not need to explain return values because output schema exists; remaining context is sufficiently addressed.

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 schema already documents operation examples and input shape. The description adds workflow context ('same operation/input pair') but does not add parameter-level detail beyond the schema, keeping this at the baseline.

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 'Estimate credits for a Cannon Studio generation request before creating billable work', a specific verb+resource with clear scope. It distinguishes itself from sibling tools by explicitly referencing get_api_operation and create_generation_request, showing where it fits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit workflow guidance: use get_api_operation first if unclear, then pass the same pair to create_generation_request after approval. It also states exclusions ('does not spend credits, enqueue jobs, or change assets') and required auth, giving clear when-to-use and when-not-to-use boundaries.

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

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

Goes well beyond the annotations (readOnly/idempotent/non-destructive) by disclosing that media is linked rather than bundled and requires network access, what the HTML contains, and that the returned filename must be used verbatim. This is the kind of behavioral detail an agent needs before invoking an export.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and delivery mechanism; the operational instructions follow. The lists of HTML contents are slightly dense but each item conveys what the export produces.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing the return — an embedded file resource with a filename to save and open — and it does so, plus notes media linking and network dependence. Only minor gaps remain, such as file size or failure conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented. The description adds marginal value by restating that HTML embeds a JSON download and JSON is machine-readable state, but adds no syntax or constraint 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?

States a specific verb (export) and resource (standalone HTML overview or versioned JSON snapshot) plus the delivery form (embedded file resource). This clearly distinguishes it from siblings like get_creator_flow_project or list_creator_flow_projects, which read rather than produce a file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives operational guidance — save the resource text verbatim to the returned filename and open the file for the user — plus a privacy caveat ('share only as requested'). It does not name an alternative or say when not to use it, but the context of use is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context not present in annotations: 'no auth, no state changes, no charges' and 'Public read-only.' This informs the agent about authentication requirements and monetary implications, exceeding what the structured metadata provides.

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 every phrase earns its place: scope, prerequisite, safety, and alternative. There is no redundant or unnecessary wording.

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 (single parameter, output schema present, strong annotations), the description covers all needed context: when to use (after search), what it does (fetch one record), and its safety profile. The output schema documents return values, so no further explanation is needed.

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 fully describes the only parameter 'id' as 'Record id returned by the search tool,' giving 100% coverage. The description repeats this by mentioning 'by id after search' and 'use search first,' but adds no new parameter-specific information beyond what the schema already provides. Baseline 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 action: 'Fetch one public Cannon Studio knowledge record by id after search.' It specifies the resource (knowledge record), the scoping (one public record), and the prerequisite (by id after search). It also implicitly distinguishes from the sibling 'search' tool by requiring an existing 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 description gives explicit usage guidance: 'use search first when you do not already have a record id.' This directly tells the agent when to use this tool versus the search tool, making the decision clear and unambiguous.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds the context of 'no auth, no state changes, no charges,' which goes beyond annotations by covering authentication and cost implications. This useful context does not contradict 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 that front-loads the core purpose, then efficiently includes usage guidance and safety traits. Every phrase adds value, with no redundant or unnecessary language.

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 one optional parameter, an output schema, and strong annotations, the description provides sufficient context: what the tool returns, when to use it, and its safety profile. No critical information is missing for an agent 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?

The input schema already describes the 'operation' parameter with a 100% description coverage, listing example operation IDs. The tool description does not add further parameter semantics, so a baseline of 3 is appropriate per the schema coverage rule.

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 'Return public docs for Cannon Studio developer API operations and payload shapes,' specifying both the verb and resource. It also distinguishes from siblings by naming estimate_generation_cost and create_generation_request as tools to use after consulting this one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to 'use this before estimate_generation_cost or create_generation_request when operation/input fields are unclear,' providing a clear when-to-use context. The safety note ('no auth, no state changes, no charges') also implies it is safe to consult as a first step.

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 destructiveHint=false, but the description adds behavioral context beyond that: 'no auth, no state changes, no charges' and 'Public read-only.' These details reassure the agent about side-effect-free operation and access requirements. 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 consists of two sentences that pack purpose, safety, and prerequisite into under 30 words. It is front-loaded with the primary function and avoids redundancy with the schema or 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?

The tool is simple (one required parameter, read-only, output URL), and the description covers purpose, prerequisite, and safety. With an output schema present and rich annotations, no additional return-format details are needed. The combination of schema, annotations, and description fully supports correct 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 input schema has 100% coverage with a detailed description of product_key, including examples. The tool description adds no new semantic information about the parameter; it only refers to 'a selected offering,' which is already captured in the schema. Therefore, 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 uses a specific verb 'Return' and identifies the resource as 'the first-party Cannon Studio checkout or inquiry URL' for a selected offering, which clearly distinguishes it from sibling tools like list_offerings or get_pricing_context. The scope is explicit: it's about generating a URL, not modifying or listing.

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 instructs to use list_offerings first to get a valid product_key, providing a clear prerequisite and sequence. It also states 'Public read-only: no auth, no state changes, no charges,' which sets expectations for safe usage conditions, but it does not enumerate alternative tools or when to avoid this one.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. Description adds beyond that: it enumerates the returned facets and states the snapshot is versioned, which is non-obvious behavioral context. Doesn't mention pagination or size limits, but adds real value over 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?

Two sentences, front-loaded with the read operation and its return facets, then the routing hint. No filler, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A read-only, single-parameter tool with full schema coverage and no output schema. The description compensates for the absent output schema by enumerating returned facets and noting the versioned snapshot, giving the agent enough to call and interpret it. Minor gap: no mention of error/auth behavior.

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 single parameter is fully documented with a clear origin ('Project ID returned by list_creator_flow_projects'). The description adds no additional meaning beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Inspect') plus a concrete inventory of what is returned (chapters, scenes, shots, visual readiness, linked media, scoped assets) and the versioned-snapshot behavior. Clearly distinct from list_creator_flow_projects (enumeration) and get_world/get_world_asset.

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 an explicit alternative and the condition that selects it ('Use export_creator_flow_project when the user wants a visual overview or file'). Does not spell out when NOT to use this tool or cover update/delete siblings, but the key routing decision is covered.

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=false, but the description goes further by enumerating side effects (updates lastPolledAt, syncs downstream task state, updates logs, delivers webhook) and explicitly listing what it does not do (create work, spend credits, cancel jobs, delete data, change assets). This significantly exceeds the annotation value.

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, front-loaded with purpose, followed by side-effect boundaries and rate guidance. Every sentence carries essential information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with side effects and an output schema, the description covers purpose, auth, side effects, exclusions, and polling behavior. It is complete enough for a developer to understand when and how to invoke it correctly, with only a minor gap around explicit sibling alternatives.

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 provides thorough descriptions for both parameters (request_id, include_logs), achieving 100% coverage. The description adds no additional parameter-level detail beyond mentioning poll_after_ms, which is not a schema parameter and could be slightly confusing. Baseline 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 opens with 'Poll and sync an existing Cannon Studio generation request by id,' which names a specific verb (poll and sync), resource (generation request), and scope (existing by id). This clearly distinguishes it from sibling tools like create_generation_request by focusing on existing requests.

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 when-to-use context: for existing requests, with OAuth/API key, and advises polling sparingly with specific intervals. It does not explicitly name an alternative tool as a comparison, so it misses the full 'when-not' guidance, 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?

The description significantly exceeds annotation coverage by stating 'no auth, no state changes, no charges.' It also discloses a behavioral limitation: availability is surface-specific and does not guarantee account eligibility or remaining credits. This adds valuable context beyond the readOnly and idempotent hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, information-dense sentence. Every clause adds value: the verb, resource, scope, safety guarantees, and limitation. It is well-structured and front-loaded with the core purpose.

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 (one optional parameter), strong annotations, and existing output schema, the description covers all essential aspects: what it lists, its read-only nature, auth requirements, and a key limitation. No critical information is missing for understanding how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides a clear description for the single 'surface' parameter with examples. The tool description does not add any parameter-specific details, but because schema coverage is 100%, the description is not required to compensate. 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's function: 'List public Cannon Studio model availability by product surface.' It uses a specific verb and resource, and the scope is defined. However, it does not explicitly differentiate from sibling tools like list_capabilities or list_offerings, relying on the unique term 'model availability' to imply distinction.

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 no explicit guidance on when to use this tool versus alternatives. It mentions a surface filter and a caveat about eligibility, but does not state scenarios like 'use this before generating a request' or compare against sibling list tools. The usage context is implied rather than stated.

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, idempotentHint, and destructiveHint, but the description adds valuable context: 'no auth, no state changes, no charges.' This goes beyond annotations by clarifying the operational and cost implications, which is especially useful for a pricing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences—first stating purpose, then usage guidelines and safety. Every word earns its place, and the key information is front-loaded. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only explanatory tool with a rich output schema and comprehensive annotations, the description fully covers what the tool does, when to use it, and important caveats (public, no charges). The output schema handles return details, so nothing is missing in 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?

Schema description coverage is 100% with each parameter clearly documented. The description does not add extra parameter semantics, but it doesn't need to since the schema carries the full load. Baseline 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 a specific verb and resource: 'Explain public Cannon Studio pricing, credits, plans, and usage tradeoffs.' It distinguishes this from sibling tools by emphasizing 'public read-only' versus purchase-path tools like list_offerings and get_checkout_link.

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 instructs when to use alternatives: 'use list_offerings or get_checkout_link only when the user asks for available purchase paths.' This gives clear context and exclusions, making it easy for an agent to route correctly.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds one useful behavioral fact — the world must be 'owned' — implying an ownership/auth constraint. Beyond that it adds no failure modes, return format, or pagination detail.

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 tight sentences with zero filler; the core action is front-loaded and the routing advice follows. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations cover the safety profile, the lone parameter is fully described in schema, and the description names the alternative tools for related needs. The only gap is that return content ('summary and media') is not elaborated, though no output schema exists to compensate.

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% for the single world_id parameter, and the schema itself documents that it comes from list_worlds. The description adds no additional parameter meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Read an owned world's summary and media.' It explicitly names the sibling tools that cover adjacent needs (list_world_assets, list_creator_flow_projects), helping distinguish it. However, 'summary and media' is loose about exact return content and it doesn't differentiate itself from get_world_asset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent to the right alternatives for adjacent tasks ('Use list_world_assets to inspect its library and list_creator_flow_projects for project discovery'), which implies when this tool is the wrong choice. It stops short of stating an explicit when-to-use condition or any prerequisites for this tool itself.

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, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the agent knows this is a safe, repeatable read. The description adds the ownership constraint ('owned library asset') and the world-scoping nuance for locations, which is useful context beyond the annotations. It does not describe return format, but with annotations covering the safety profile, a 3 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?

Two concise sentences with no waste. The primary action is front-loaded, followed by a usage hint. It is appropriately sized for a read tool with a small schema.

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 3-parameter read tool with no output schema and rich annotations, the description covers the core action and some parameter context. However, given 0% schema coverage, it should explain the parameters more fully (e.g., what identifiers look like, the kind enum implications). It is minimally adequate but has clear gaps in parameter explanation.

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%, meaning the schema provides no descriptions for the three parameters. The description mentions 'kind' and 'world_id' from discovery and that 'locations may be world-scoped,' which adds some meaning for world_id's conditional relevance. However, it does not clarify asset_id, kind enum values, format, or constraints. With 0% schema coverage, the description fails to compensate adequately for the parameter documentation 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?

States a specific verb+resource: 'Read one owned library asset's descriptive state and media.' This distinguishes it clearly from write siblings (create_world_asset, update_world_asset, delete_world_asset) and from list_world_assets. It does not explicitly name list_world_assets or get_world as the alternative for discovery, but the 'one' vs list distinction is implicit.

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 says 'Use the kind and world_id from discovery,' which gives a sequencing hint about where to obtain parameter values. However, it doesn't state when to use this tool versus get_world or list_world_assets, nor does it provide exclusions. Usage is implied but not explicitly framed.

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?

Although annotations already declare readOnly/idempotent/non-destructive, the description adds key context: 'no auth, no state changes, no charges.' This goes beyond annotations by clarifying authentication requirements and cost implications, which are critical for an agent to decide whether to call the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences that front-load the core purpose and then pack usage guidance and behavioral notes into the second sentence. Every word contributes, with 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?

With an output schema, return values are already defined. The description covers filters, auth/charges, and directs to search/fetch for deeper source text. It is slightly incomplete in not differentiating from similar list tools like list_offerings and list_toolkits, which is relevant given the sibling set.

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 100% descriptive coverage for all three parameters, with examples in each property description. The tool description only restates the filter dimensions ('audience, workflow, or output type') without adding new semantic meaning, so it meets the baseline but adds no extra value.

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 public Cannon Studio capabilities, with a specific verb ('list') and resource ('capabilities'). It distinguishes from search/fetch by directing deeper source-text needs elsewhere, but it does not explicitly differentiate from sibling tools like list_offerings or list_toolkits.

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 search or fetch when deeper source text is needed, providing a clear when-not-to-use scenario. However, it does not mention alternatives such as list_offerings or list_toolkits, so the guidance is partial.

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 declare readOnlyHint=false, which is counterintuitive for a list operation; the description resolves this by disclosing 'May backfill legacy collaboration indexes,' explaining the non-idempotent-write nature. It also previews return contents, though it doesn't describe pagination 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?

Three sentences, front-loaded with what is returned, followed by the behavioral caveat and the entry-point hint. No filler; every sentence carries distinct 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?

With no output schema, the description compensates by listing the returned fields, and annotations plus the backfill note cover the behavioral profile. Pagination is handled by the schema-described cursor parameter, leaving little an agent would need to call 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?

Both parameters (limit, cursor) have full schema descriptions ('Maximum returned records.', 'Last returned ID, for the next page.'), so coverage is 100%. The description adds no parameter-level detail, which is the correct baseline when 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?

States a specific verb (Discover/list) and resource (Creator Flow projects) and enumerates the returned fields: IDs, roles, direct links, final videos. It implicitly distinguishes itself from the singular sibling get_creator_flow_project by covering 'owned and shared' projects at list scope.

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?

'Start here when the user mentions their project' gives explicit entry-point guidance, which is exactly what a list/discovery tool needs. It stops short of naming alternatives (e.g., get_creator_flow_project when an ID is already known), so no exclusions are stated.

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, idempotentHint), the description adds concrete behavioral details: no auth, no state changes, no charges, and specifically that it returns first-party URLs without creating Stripe sessions or granting credits. This significantly clarifies side effects and auth requirements, exceeding what the annotations alone convey.

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-loads the primary purpose in the first sentence, and uses the second for essential behavioral constraints. Every clause 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?

With an output schema present, return values are documented elsewhere. The description covers the critical context: it's a public read-only listing, no auth or side effects, and the exact behavior regarding URLs and Stripe sessions. Given the simple optional parameters and existing annotations, this is fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for all three parameters (kind, interval, include_checkout_links). The description does not add parameter-specific semantics beyond what the schema provides, 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 opens with a specific verb and resource: 'List public Cannon Studio plans, credit packs, and team offerings.' This clearly identifies the tool's function and categorizes what it returns, distinguishing it from sibling tools like list_capabilities and list_toolkits by focusing on offerings.

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 usage context: 'Public read-only: no auth, no state changes, no charges' tells the agent this is safe to call without credentials or side effects. The phrase 'without creating Stripe sessions or granting credits' implies when not to use it, contrasting with tools like get_checkout_link, though it doesn't explicitly name an alternative.

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 beyond annotations by explicitly stating 'Public read-only: no auth, no state changes, no charges.' This adds valuable context about access control, side-effect freedom, and cost, which is highly relevant for agent decision-making. It aligns with the readOnlyHint and destructiveHint annotations 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 a single, information-dense sentence that front-loads the action and resource, lists key categories, and includes crucial safety/behavioral notes. 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 description is largely complete for a read-only list tool with no required parameters. It explains the purpose, routing nuances, and safety profile. However, it does not explicitly compare with sibling listing tools or describe output structure, though the presence of an output schema mitigates the latter. Overall, it covers the essential context well.

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 provides complete descriptions for all four parameters (action, family, media_type, project_context_only), and the description does not add additional parameter-level semantics. Since schema coverage is 100%, the baseline of 3 is appropriate; the description's focus is on output characteristics rather than parameter guidance.

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: listing specific categories of Cannon Studio toolkit surfaces (image, video, audio, etc.) and highlighting API vs. app/Director Mode routing. This specific verb+resource scope distinguishes it from sibling tools like list_capabilities and list_offerings.

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 on what information the tool returns (which toolkits are API operations vs. app/Director Mode), which signals when to use it. However, it does not explicitly mention alternatives or when not to use it, so it misses the highest bar of explicit exclusions.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuinely useful behavior beyond annotations: pagination mechanics via next_cursor and the discovery-first pattern. It doesn't cover rate limits or ordering, keeping this from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the discovery-then-page action and the return shape. Every clause earns its place; only the mild redundancy of naming 'asset IDs, descriptions, media links' borders on filler, but it aids selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only paginated list with no output schema, the description covers the workflow (discover, select kind, page), optional filters, and return contents. Adequate for correct invocation; missing only ordering/rate-limit detail that annotations don't supply.

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 50%: limit and cursor are documented in the schema, but kind and world_id lack descriptions there. The description compensates partially by stating kind is a selector and world_id is an optional filter, and it explicitly mentions next_cursor semantics via 'page through'.

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 (list/page through) and enumerates the asset kinds it lists (characters, locations, objects, outfits, abilities, cameras). This distinguishes it from sibling tools like get_world_asset (singular fetch) and update/delete_world_asset, though it doesn't explicitly name the alternatives.

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?

Implies usage ('Select kind; optionally filter world_id') and describes a discovery-then-paginate flow, but gives no explicit when-to-use vs siblings like get_world_asset or search. An agent can infer this is the bulk-listing tool, but routing isn't spelled out.

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

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

Annotations already establish the safe-read profile (readOnly, idempotent, non-destructive, closed-world), so the description sensibly spends its words on pagination behavior instead. Stating that a next_cursor is returned when more worlds exist is useful operational context the annotations cannot convey, though pagination semantics (e.g., passing cursor back) are not spelled out.

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 tight sentences, front-loaded with the action and scope, followed immediately by the pagination contract. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates the returned fields (titles, descriptions, media, direct links) and the pagination signal, which are the key facts an agent needs. Minor gaps remain around default page size and how to resume paging, but nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both limit and cursor are already documented in the schema, making 3 the baseline. The description reinforces that results are paged and a cursor is returned, but adds no syntax or format detail 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?

States a specific verb ('page through') and resource ('your owned worlds'), and the 'owned' qualifier scopes it away from a general world search. It does not name the read-one sibling (get_world) or search, so differentiation is implied rather than explicit.

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?

Pagination context is implied by 'Page through' and the next_cursor note, giving some sense of when to use it. However, there is no guidance on when to prefer this over get_world or search, and no statement of prerequisites.

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 idempotentHint=true, but the description adds valuable context: 'no auth, no state changes, no charges.' This goes beyond the annotations and helps the agent understand safety and side-effect profile, especially since openWorldHint=false adds nuance. 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?

Two sentences, zero waste. The first sentence states the core purpose, and the second adds safety and usage constraints. Information is front-loaded and each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity, the presence of a full output schema, and strong annotations, the description covers all essential aspects: purpose, safety, and usage boundary. It is complete without needing to explain return values, which are handled by the 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 100%, with all five parameters well-described in the schema. The description itself only mentions 'stated creative or developer goal' for the goal parameter, adding minimal extra meaning. Baseline 3 applies since 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 uses the specific verb 'Recommend' with the resource 'Cannon Studio workflow' and targets a 'stated creative or developer goal,' clearly distinguishing it from siblings like create_generation_request and estimate_generation_cost. It unambiguously states what the tool does.

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 'use this for planning, not to create generation jobs,' providing clear when-to-use and when-not-to-use guidance. It does not name specific alternative tools, but the exclusion is strong enough to guide selection. It also notes 'Public read-only' as situational context.

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 indicate a safe read-only operation; the description adds 'no auth, no state changes, no charges' and explains that returned ids can be used with fetch for full text, revealing that search results may not be complete documents. This goes beyond what annotations and schema provide.

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: first states purpose and usage triggers, second discloses safety and follow-up action. No redundant phrases, highly scannable.

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 purpose, usage context, safety profile, and relationship to fetch, while the output schema documents return structure. This is sufficient for a read-only search tool with a rich 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 100%, so all five parameters are documented in the input schema. The description itself doesn't elaborate on individual parameters but does contextualize the query parameter as natural-language over public knowledge. Baseline 3 is appropriate when the schema carries the parameter detail.

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 'Search public Cannon Studio knowledge' with a specific verb and resource. It lists common query types (products, workflows, pricing, models, comparisons, use cases, developer API docs), distinguishing it from sibling tools like fetch which retrieves full text by 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 description specifies when to use the tool ('when a user asks about...') and explicitly directs to 'call fetch with a returned id when full source-backed text is needed', providing clear guidance on an alternative. It doesn't enumerate all sibling alternatives, but the context is sufficient.

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

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

Annotations already declare non-readOnly, non-destructive, non-idempotent, non-openWorld, so the safety profile is covered. The description adds genuinely new context: editor-level authorization is required, concurrent edits are mediated by another collaborator's edit lease, and media is left untouched. It does not explain the practical consequence of non-idempotency (e.g. repeated calls or partial-failure behavior), leaving one gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences with zero filler: capability first, then preconditions, then scope exclusion. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and 4 params, the description covers access, concurrency, and scope, but omits the highest-value unknown for an updater: whether fields not supplied are preserved or cleared. Without that, an agent cannot safely predict the effect of a partial update.

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% (just project_id is documented), so the description must compensate. It does enumerate the three editable fields, which is some value, but adds nothing about limits (e.g. title maxLength 180, summary maxLength 4000), whether omitted fields are left unchanged (patch semantics), or that visualStyle reuses the summary shape. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Edit) plus the exact editable fields (title, summary, visual style) on a named resource, and the closing clause 'Does not regenerate media' distinguishes it from generation siblings like create_generation_request. It stops short of naming a sibling alternative directly, so it is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete preconditions — 'Requires editor access' — and a usage constraint — 'respects another collaborator's active edit lease' — plus a negative scope statement about media regeneration. No explicit alternative tool is named for cases where the agent lacks editor access, so guidance is strong but not exhaustive.

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 declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries useful extra weight: it discloses PATCH-style partial-update semantics and, importantly, that empty strings/arrays clear optional fields, plus that existing media is untouched. No auth or rate-limit details, but the mutation semantics are well covered.

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, front-loaded sentences with no filler. Each sentence earns its place: purpose, update semantics, and the media boundary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and annotations cover only safety, so the description is the main source of behavioral context. It addresses clearing and omission semantics but omits the field inventory and any permission/ownership requirements, which matters for an 8-parameter mutation tool with 13% schema coverage.

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 13% (only world_id is documented), so the description must compensate for seven undocumented parameters. It conveys the string-vs-array clearing behavior for optional fields but never enumerates the updatable fields (genre, theme, title, description, visualStyle, importantLore, videoProductionCues), leaving their meaning and constraints to the schema names 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?

Names a specific verb and resource ('Update an owned world's descriptive fields') and scopes it away from non-descriptive content with 'Does not rewrite existing media', which implicitly separates it from update_world_asset. It does not explicitly name a sibling, so it falls just short of full sibling differentiation.

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 partial-update usage through 'Omitted fields remain unchanged', which tells the agent how to call it, but there is no explicit when-to-use / when-not-to-use guidance and no mention of alternatives such as create_world, update_world_asset, or delete_world.

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 provide mutation safety profile (readOnlyHint=false, destructiveHint=false). The description adds that it edits existing fields and media references without generating new media, but doesn't state permissions, reversibility, or partial-update behavior. With annotations covering basics, a 3 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?

One efficient sentence with a clarifying second clause. Front-loaded with the core action. No wasted words, though could benefit from more structure for 11 parameters.

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 mutation tool with no output schema and 0% schema coverage, the description is too sparse. It doesn't explain required vs optional parameters, the meaning of 'kind' enum, or return expectations. Incomplete for the tool's complexity.

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% and there are 11 parameters, so the description carries full burden. It mentions 'descriptive fields' and 'existing media references' but doesn't map to specific parameters like kind, asset_id, or the array max of 20. Significant gap for an 11-param tool.

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 a specific verb+resource ('Edit an owned reusable asset's descriptive fields and existing media references'), clearly distinguishing from create_world_asset and delete_world_asset. It doesn't explicitly name siblings, but the 'Edit' vs 'Generate' distinction is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Does not generate new media' implies avoidance of generation tools, but no explicit when-to-use guidance or named alternatives. For a mutation tool with multiple siblings, more routing information would be beneficial.

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