Tintin Tryon

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

Annotations already mark this as readOnly and openWorld, and the description adds rich behavioral context: it scans a public sitemap, checks specific criteria (≥180 days, season mismatches, retail-calendar windows), and returns work orders with estimated credit costs. This goes well beyond the annotations and provides clear expectations about what the tool does and produces. No contradiction exists.

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

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

The description is exactly two sentences: the first states the core purpose and a key constraint (no account needed), the second details the scan criteria and return value. Every clause adds value, and the most important information is front-loaded. There is no wasted text.

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 single required parameter and the presence of an output schema, the description is fully complete. It explains what the tool does, how it works (sitemap scan), what it detects, and what it returns (work orders with pre-filled fixes and credit costs). It also orients the user in the broader toolset by linking to create_tryon_job.

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 well-described 'store_url' parameter (domain/URL with example). The description does not add additional parameter semantics, so the baseline score of 3 is appropriate—the schema fully handles parameter documentation.

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

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

The description opens with a specific verb and resource ('Audit a Shopify store's listing photos'), clearly distinguishing it from sibling create/get tools. It further elaborates with concrete audit dimensions (stale photos, season mismatches, retail-calendar windows), leaving no ambiguity about the tool's function.

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 states 'no account needed' and 'Scans the public product sitemap,' implying this is for public store audits without authentication. It also references 'pre-filled create_tryon_job fixes,' showing a clear workflow connection to that sibling tool. However, it stops short of explicitly saying when not to use this tool or naming alternatives, so it earns a 4 rather than a 5.

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

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

Beyond the annotations (readOnlyHint false), the description discloses key behavioral constraints: one free preview per store, no account required, and the need to poll with get_preview_status. It also clarifies that the generating is free and produces a 2K image, adding meaningful context for the agent.

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 extremely concise—two sentences—and front-loaded with the most critical constraint (one free preview per store). Every word adds value, with no filler or repetition of schema details.

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

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

Given the tool has 4 parameters (2 required) and an output schema, the description covers the prerequisite (audit_store work order), the free/limit constraint, and the follow-up polling step. It is sufficiently complete for an agent to select and invoke the tool correctly without additional context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds limited extra meaning beyond the schema, mainly connecting store_url and garment_image_url to an audit_store work order, which the schema already partially states. No significant new parameter-level details are provided.

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

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

The description clearly states the tool creates a free 2K on-model try-on preview, specifying the exact inputs (store and listing photo URL) and distinguishing it from the paid create_tryon_job and the polling get_preview_status. The phrase 'taste before buying credits' reinforces its specific purpose.

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 conveys when to use the tool ('taste before buying credits') and provides usage context (one free per store, no account needed, from an audit_store work order). However, it does not explicitly name the paid alternative or state when not to use it, so it falls short of explicit when/when-not guidance.

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

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

The description discloses significant non-obvious side effects: charging credits ('1 credit (2K) or 2 credits (4K)') and requiring an API key. This adds value beyond the annotations, which only indicate readOnlyHint=false and openWorldHint=true, and aligns with the mutating nature of 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, front-loaded with the core action, followed by concise cost and auth information. There is no redundant or filler content.

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 job-creation tool with 8 parameters and an output schema, the description covers purpose, cost, and prerequisites. However, it omits the asynchronous nature of job processing (e.g., that the job returns a status to poll via get_job_status) and how results are retrieved, which would be valuable for a complete context.

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

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

The input schema already provides descriptions for all 8 parameters (100% coverage), so the tool description adds little parameter-level detail. It mentions the garment_image_url concept but does not enrich any parameter meanings beyond what the schema already states.

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

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

The description clearly identifies the tool's function: 'Generate an on-model try-on photo from a garment/product image URL'. The verb 'Generate' and resource 'try-on photo' are specific and distinguish this from sibling tools like audit_store and create_preview_job, even though no sibling is explicitly named.

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 by giving an example ('e.g. straight from an audit_store work order') and specifying prerequisites (API key, credit cost). However, it does not explicitly state when to use this versus create_preview_job or any exclusions, so it's clear but not fully comparative.

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

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

Beyond the readOnlyHint annotation, the description adds useful behavioral context: the API key requirement and the presence of a top-up link in the response. This goes beyond what annotations convey, even if it doesn't detail the full response shape.

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 short, front-loaded sentences. The core purpose comes first, followed by the auth requirement. No fluff or redundant elaboration.

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

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

For a simple read-only tool with one optional parameter, output schema, and clear annotations, the description covers the essential purpose and auth prerequisite. 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 coverage is 100% for the only parameter. The description's 'Requires an API key' restates the parameter description without adding new semantics. Baseline 3 applies because the schema already documents the parameter adequately.

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

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

The description clearly identifies the tool's function: retrieving the studio credit balance and providing a top-up link. It is distinct from sibling tools (audit, jobs, preview, seasonal guide) and leaves no ambiguity about what it 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 gives clear context (checking credit balance) and a key prerequisite (API key required). It doesn't explicitly mention when not to use it, but since no sibling tool covers credits, explicit alternatives aren't necessary.

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 adds meaningful behavior beyond the readOnlyHint annotation: it discloses that on success the tool returns presigned output image URLs valid for 1 hour, and that an API key is required. This gives useful context about the response format and authorization.

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 short sentences, front-loaded with the primary action, and every word adds value. There is no filler or redundant restatement of the tool name or title.

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, the description need not explain every return field. It covers the key behavioral nuance (URL expiry), the auth requirement, and the core polling action. It could mention failure states or polling cadence, but overall it is sufficiently complete for a read-only status tool.

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

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

The input schema already provides 100% coverage with clear descriptions for both parameters. The description mentions an API key requirement, reinforcing the api_key parameter, but adds no new semantic meaning beyond what the schema already conveys.

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 action ('Poll a generation job') and describes the key successful outcome ('returns presigned output image URLs'). It is unambiguous about the resource being polled, though it does not explicitly differentiate from the sibling get_preview_status tool.

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 after creating a job ('Poll a generation job') and notes the API key requirement. However, it does not explain when to choose this tool over alternatives like get_preview_status, nor does it mention any exclusions or prerequisites beyond API key.

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

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

Beyond the readOnlyHint annotation, it discloses that no account is needed and that the returned URL is valid for 1 hour. This adds practical context about rate limits/lifetime without contradicting annotations.

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

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

Three short sentences, each providing unique value: purpose, success result, and access requirement. No redundancy, perfectly 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 simple poll tool with one parameter and an output schema, the description is complete. It mentions the success response, URL validity, and no-account requirement, covering all necessary usage 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 coverage is 100% with a detailed description for preview_id ('Preview UUID returned by create_preview_job'). The description adds no additional parameter semantics beyond what the schema already covers.

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 polls a preview and returns the preview image URL on success. The verb 'Poll' and resource 'preview' make it distinct from sibling tools like get_job_status, which is more generic.

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 clear context for when to use: polling a preview until success. It does not explicitly exclude get_job_status or mention alternatives, but the 'free preview' scope makes the intended use obvious.

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 readOnlyHint, the description adds useful context: no account required, and that statuses are 'right now' (time-sensitive). This gives behavior insight beyond annotations. No contradictions.

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 key purpose and includes all vital details (windows, deadlines, links) without redundancy. Every word 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?

With an output schema present, the description does not need to explain return values. It covers what the tool offers, auth requirements, and time-sensitivity, making it complete for a relatively simple read-only tool.

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

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

The sole parameter 'category' is fully described in the schema with enum values and optionality. The description mentions 'per-category shoot guides' but adds little beyond the schema; baseline 3 is appropriate given 100% schema coverage.

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

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

The description clearly states what the tool does: provides a retail shoot calendar for fashion sellers, detailing which shoot windows are open or urgent, deadlines, and links to per-category guides. It is specific and distinguishes from siblings like audit_store or job status 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 implies usage: when a seller needs to know current shoot windows and deadlines. It mentions 'no account needed' and gives clear context, but does not explicitly state when not to use or name alternatives, though siblings are clearly different in purpose.

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