Uwear

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

Annotations already declare destructiveHint=true, and the description aligns with this by saying 'fill or replace.' It adds a behavioral nuance: 'Creator-linked slots keep their source guard,' which is not present in the schema or annotations and helps the agent understand source-ownership constraints.

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

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

The description is two sentences long and front-loaded with the core action. Every word adds value—no redundancy or filler.

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

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

The description covers the key logic (one-of sources, replace semantics) and a notable edge case (creator-linked slots) for a destructive mutation. There is no output schema, so not specifying return values is acceptable, but slightly more detail on the result (e.g., success/failure behavior) would make it 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?

Schema coverage is 100%, so all parameters are already well-documented with descriptions like 'Use exactly one source field.' The description mostly echoes these source types without adding new syntax or format details, so it earns the baseline score for high 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 the action ('fill or replace'), the target resource ('reference slot on an existing owned avatar/model'), and the three source types (workspace file, generation result, public URL). It distinguishes from sibling tools like create_avatar_from_references by explicitly mentioning 'existing' avatar/model.

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

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

The description implies when to use the tool—updating an existing avatar's reference slots—which is distinct from creating a new avatar or generating one. It does not explicitly name alternatives or exclusions, but the 'existing' qualifier provides clear contextual 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?

Beyond the annotations, the description discloses the asynchronous generation behavior by stating it 'Returns generation_id' and instructs the agent to poll status before fetching results. It also clarifies the exclusivity constraint without contradicting annotations. It does not discuss side effects on source assets or error conditions, but the 'replace' language combined with destructiveHint=false is not contradictory.

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?

Four short sentences deliver the outcome, source requirements, mode-to-parameter mapping, and lifecycle instructions with no filler. The most important constraint ('exactly one foreground source') appears early, and the follow-up flow is front-loaded before any less critical 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?

For a tool with no output schema and six parameters, the description covers what is needed to invoke the tool correctly: source selection, mode mapping, required parameters, and the return/status/result workflow. It also notes the public HTTPS requirement for image URLs. An agent has enough context to understand both the call and the subsequent polling 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?

The schema already has 100% parameter coverage and describes each field individually. The description adds value by explaining cross-parameter relationships: exactly one foreground source must be chosen, and each backdrop_mode requires a specific supporting parameter. This is meaningful semantic information beyond the flat schema.

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

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

The description opens with a specific action, 'Remove or replace an image background,' and identifies the exact resource and path: 'Uwear's canonical free backdrop generation path.' This clearly distinguishes the tool from siblings like generate_avatar or upload_garment_from_public_url, which serve different purposes.

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 operational guidance: 'Provide exactly one foreground source' and maps each backdrop_mode to its required parameter. It also specifies the follow-up flow: 'poll get_generation_status, then fetch get_generation_results.' However, it does not name alternative tools or state when not to use this tool, so it stops short of a full 5.

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

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

With all annotations false, no safety or behavioral hints are provided, so the description carries the burden. It clearly discloses that the tool queues work asynchronously and returns a job ID, requiring polling. It also mentions Uwear's prompt system and the save semantics. It does not fully detail all side effects, but the key async behavior is transparent.

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

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

The description is three sentences with no wasted words. It front-loads the primary action, then explains the save distinction, and ends with the required follow-up polling call. Each sentence earns its place and the structure is easy to scan.

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 asynchronous tool with no output schema, the description covers the essential flow: queue, save vs draft, and polling. It does not mention all parameters, but the schema fully documents them. It also lacks an explicit distinction from the sibling create_art_direction, but the async and job-ID details provide sufficient 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 has 100% coverage with detailed descriptions for all parameters. The tool description adds value by reinforcing the save parameter's meaning, but it does not provide additional semantics beyond the schema for sources, user_text, image_urls, or reference_image_attachments. The baseline of 3 is appropriate when the schema already documents parameters thoroughly.

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

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

The description states a specific action ('Queue the conversation') on a specific resource ('for asynchronous ArtDirection authoring using Uwear's prompt system'). It distinguishes itself from synchronous creation by explicitly mentioning asynchronous processing and returning a job ID. The save=true/false distinction further clarifies the two modes of operation.

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 guidance on when to use save=true versus save=false, and instructs the caller to poll get_art_direction_authoring_job until done. It does not explicitly name alternative tools (e.g., create_art_direction or iterate_art_direction), but the async and polling context implies when this tool is appropriate.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing this as a safe, read-only, idempotent operation. The description adds the context that it should be skipped when the input prompt is already specific, which is useful but not a major behavioral disclosure. Since annotations cover the safety profile, this is adequate.

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, front-loaded with the purpose and followed by usage guidance. No redundant phrasing.

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

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

For a simple, side-effect-free tool with no required parameters and full schema coverage, the description covers the core purpose and the key decision of when to skip it. It doesn't explicitly state the return format, but the tool name and description imply a prompt string, and annotations cover safety. Complete enough.

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?

All 5 parameters are fully described in the schema (100% coverage), so the description doesn't need to repeat them. The description's mention of 'user's rough description' aligns with the user_text parameter, but the schema already documents each parameter thoroughly. 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 tool's function: building a highly detailed prompt for avatar/model generation. It distinguishes itself from the sibling generate_avatar by explicitly saying that if the user's prompt is already intentional, the system can skip this and pass wording directly to generate_avatar, making sibling differentiation 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 description gives explicit conditions for when to use this tool ('when the user wants help describing a person before image generation') and when to skip it in favor of an alternative ('if the user's prompt is already intentional and specific... pass directly to generate_avatar'). This directly addresses usage vs alternatives.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=true, and the description aligns with and reinforces these. The description adds meaningful context beyond annotations: it explains idempotency behavior in detail ('Repeated calls return or resume the same durable execution') and the execute=true default nuance. Not a 5 because it doesn't detail what destructive side effects occur or any specific auth/precondition requirements, but with the annotation set present, this is solid coverage.

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

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

The description is a single, dense paragraph of four sentences, each adding value: purpose, MCP semantics, brief_id scoping, and idempotency. It's front-loaded with the core purpose. Slightly less than a 5 because the MCP-phrase guidance is embedded in the middle rather than separated, and could be tightened, but there's no waste.

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 2-param tool with 100% schema coverage and no output schema (so no need to describe return values), the description covers purpose, idempotency, parameter semantics, and usage context. The only minor gap is not explaining what 'execute' actually does post-confirmation (what gets generated/started) or any rate-limits/duplication risks. Given the tool's simplicity, this is well-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 adds some context for the 'execute' parameter by explaining the MCP-default behavior, and clarifies the brief_id type (visible persisted brief). However, it doesn't add much beyond what the schema's own parameter descriptions already state; the schema description of 'execute' is quite thorough already. 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 what the tool does: 'approve and idempotently execute a visible persisted Uwear brief.' It uses a specific verb+resource combination and distinguishes itself from siblings like propose_brief and update_brief by focusing on the confirm+execute action. The brief_id scoping ('visible/latest BriefProposal') further disambiguates it.

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

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

The description provides explicit guidance on MCP phrasing that should map to execute=true ('Confirm', 'looks good', 'run it', 'start', 'generate') versus when to set execute=false ('only when the user explicitly wants to save approval without starting generation'). It also references the related brief_id source (visible/latest BriefProposal), guiding which ID to use. This is explicit, actionable 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 declare readOnlyHint, idempotentHint, and destructiveHint, lowering the burden. The description adds valuable behavioral context beyond annotations: the result carries no live Template dependency, does not update a Workflow, and is meant for insertion through other authoring tools. This clarifies the 'read-only' nature as non-mutating to existing workflow resources.

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

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

The description is a single dense sentence that front-loads the core operation and immediately states the most important constraints: detached, no workflow update, no live dependency, and insertion via canonical authoring tools. No wasted words.

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

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

For a tool with two well-documented parameters and safety-focused annotations, the description covers the essential context: what the output is, what it is not, and how it should be used downstream. It does not describe the exact return shape, but no output schema exists and the copy/config semantics make that less critical.

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 parameter meaning is fully carried by the schema. The description does not add new parameter-level details beyond the schema, but it does reinforce the conceptual role of contract_version through 'contract-typed' phrasing. 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?

States a specific verb and resource: copies a generation-preset Template into a contract-typed, detached Production Workflow Generate-node config. It clearly differentiates from sibling tools like save_template, get_template, and delete_template by emphasizing detachment and the absence of a live Template dependency.

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 usage context: the tool produces a detached config that should be inserted through the canonical workflow version authoring tools. It explicitly says it does not update a Workflow, which sets expectations, though it does not name specific alternative tools for when a live workflow update is desired.

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

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

Annotations are all false, so no protective or destructive hints are present. The description adds the key nuance that this is a direct writer for already-structured markdown, but it does not disclose other behaviors such as validation, overwrite semantics, or return values. The parser contract is also repeated in the schema, so the marginal description value is moderate.

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: the first states the purpose and the second gives usage guidance. It is front-loaded, scannable, and contains no filler, making it an exemplar of concise yet informative writing.

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 creation tool with no output schema and moderate complexity, the description covers the essential decision of when to use it and what input it expects. It could mention the result of the creation (e.g., saved entity) or any side effects, but the sibling tools and schema fill most gaps. A score of 4 reflects solid but not exhaustive completeness.

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 detailed explanations for all three parameters. The description does not add extra parameter semantics beyond referencing the parser contract in content_markdown, 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 begins with 'Create a company ArtDirection markdown document,' using a specific verb and resource. It immediately distinguishes the tool from its sibling author_art_direction by noting when to prefer that alternative. This makes the purpose clear and uniquely positioned among the 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 states to use author_art_direction first for rough creative text or reference images, and to use this direct writer only for already-structured markdown that follows the Variation Controls parser contract. This provides clear when-to-use guidance and names the 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?

Annotations already indicate non-read-only and destructive hint, but the description adds behavioral context: references fill durable slots, traits are never inferred, and the avatar is reusable. This goes beyond annotations, though it doesn't elaborate on the destructive nature.

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

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

Two sentences, front-loaded with the main purpose, no redundant info. Each sentence adds key information (inputs, slot concept, trait handling).

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

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

Given the tool's complexity (nested objects, 5 params) and no output schema, the description omits return value and potential side-effect details like what happens on name collision. The core concept is well covered, but agent would benefit from knowing what is returned.

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

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

Schema coverage is high (80%), and the description clarifies semantic aspects not in the schema: references are ordered, slots are durable, and trait parameters (build, age, height) are never inferred. This adds meaning beyond the raw schema definitions.

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

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

Clearly states the tool creates a reusable avatar/model from specific input types (generated views, workspace files, URLs). Uses a specific verb ('create') and resource ('avatar/model'), distinguishing it from sibling tools like generate_avatar.

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?

Describes the input composition (ordered references, optional traits) but provides no explicit when-to-use vs alternatives or exclusions. Contexts like 'generate_avatar' exist as siblings but the description doesn't differentiate when this tool should be chosen instead.

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

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

Annotations indicate a mutating operation (readOnlyHint=false), and the description adds important behavioral context beyond that: 'The tool only creates a payment link; the user must open and complete payment in Stripe.' This clarifies that the tool does not finalize the purchase. However, it does not mention potential side effects like whether credits are reserved or any authorization requirements.

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

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

The description is four sentences, each earning its place: purpose, usage, exclusion, and behavioral limitation. It is front-loaded with the core function and contains no redundant 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 has no output schema, but the description implies the return is a Stripe Checkout URL and indicates user action is needed. This is sufficient for basic invocation. It lacks detail on the response format or any post-payment flow, but given the moderate complexity and strong annotations, completeness is adequate.

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 every parameter documented. The description adds overall context but does not elaborate on parameter-specific semantics beyond the schema. Baseline 3 is appropriate since the schema carries the full parameter meaning.

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

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

The description opens with a specific verb and resource: 'Create a hosted Stripe Checkout URL for buying Uwear generation credits.' This clearly distinguishes the tool from siblings like get_user_credits and estimate_cost. The scope is unambiguous.

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

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

Explicit usage criteria are provided: 'Use only when the user explicitly asks to buy, add, top up, or purchase credits, or when they ask how to continue after insufficient credits.' It also states a clear exclusion: 'Do not call during photoshoot planning unless the user requested checkout.' This gives the agent strong decision 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?

With annotations only providing false hints for readOnly, openWorld, idempotent, and destructive, the description adds meaningful behavior: the backend analyzes the image if description is omitted, and the tool returns a location_id for reuse. This goes beyond the schema and annotations, though it doesn't disclose potential side effects or validation rules.

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

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

The description is two sentences, front-loaded with the core purpose, and every clause earns its place. It efficiently conveys creation, the optional-description behavior, and the output usage without extraneous words.

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

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

For a create tool with 6 parameters and no output schema, the description covers the core workflow (image URL -> location reference), the optional-description behavior, and the required output hint (location_id). It stops short of describing full response structure or error cases, but the essential context for an agent to invoke it correctly 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?

The input schema already provides descriptions for all 6 parameters, including the optional description field and its image-analysis fallback. The tool description repeats this internal behavior but does not add new parameter-level meaning. Since schema coverage is 100%, the score is at baseline 3, with no significant value added by the description.

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-resource pair ('Create a reusable location/scene reference') and clearly differentiates from sibling tools like get_location and list_locations by focusing on creation. It also states the intended downstream use in propose_brief/update_brief, which solidifies its unique role.

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 the returned location_id in propose_brief/update_brief, giving clear context for when this tool is appropriate. It does not list exclusions or alternatives, but the workflow reference implies the use case sufficiently.

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 communicate that the tool is mutating (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds minimal context by clarifying that it pairs existing garments without uploading new images, but it does not disclose additional side effects, permissions, or return behavior beyond what is implied.

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 concise sentences, with the primary purpose front-loaded and no redundant or extraneous information. 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?

For a simple create operation with full schema coverage and clear annotations, the description adequately explains the tool's functionality. The lack of an output schema is not a major gap given the straightforward nature of the operation.

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 all three parameters, so the description does not need to add parameter-level details. The description implicitly references the purpose of clothing_item_ids but adds no new semantics beyond the schema.

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

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

The description clearly states the action (create), the resource (outfit), and the source (existing garment IDs). It also distinguishes from upload-related tools by noting that no new images are uploaded, making the purpose unambiguous.

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

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

The description implies usage when garment IDs already exist and an outfit needs to be composed, but it does not explicitly state when not to use the tool or mention alternatives like propose_outfits or upload_garment_from_chat_file. No exclusions are provided.

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 readOnlyHint=false and destructiveHint=false. The description adds the workspace requirement but doesn't disclose uniqueness enforcement or idempotency-related behavior (e.g., what happens if a duplicate name is submitted). 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 a single front-loaded sentence that communicates the core functionality. The asset type list is slightly detailed but remains compact and useful.

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 create tool with full schema coverage and no output schema, the description and schema together provide sufficient guidance. It could mention return values or duplicate-name behavior, but these are not critical for tool selection and invocation.

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 both parameters fully described (name with uniqueness and maxLength; color with format example). The description adds no parameter-specific meaning beyond listing asset types, so 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 ('Create a new tag'), the resource ('for organizing assets'), and enumerates the asset types. This distinguishes it from sibling tools like list_tags and get_items_by_tag, which have different purposes.

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 a clear precondition ('Requires an active company workspace') and indicates a broad use case (organizing assets). It doesn't explicitly name alternatives or when-not-to-use scenarios, but the context is sufficient for a simple create tool.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds the behavioral trait of permanence ("Permanently delete") and an ownership constraint, which are not explicitly stated in annotations. This goes beyond the minimal annotation information.

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, clearly front-loaded with the action and resource. No redundant phrasing or filler. Every word adds value.

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 delete tool with one parameter and no output schema, the description covers the essential context: permanent deletion and a key caveat about owner-only templates. It could mention error conditions or permissions, but given the tool's simplicity, it is sufficiently 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 schema covers 100% of parameters with a single template_id and its description. The tool description does not add significant semantic detail beyond the schema, and the schema already describes the template as a 'company template.' The parameter is straightforward, 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?

The description clearly states the action: "Permanently delete a library template." This uses a specific verb (delete) and resource (library template), which directly distinguishes it from sibling tools like get_template, save_template, and list_templates.

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 includes an important usage exclusion: "Owner-only templates must be deleted through their owning resource." This provides guidance on when NOT to use this tool, implying an alternative exists. It could be improved by explicitly stating the general use case (delete any library template) but the purpose makes it evident.

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

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

Annotations indicate a non-read-only, non-destructive mutation (readOnlyHint=false, destructiveHint=false). The description adds context that the copy is 'editable' and that the source can be system or company, but it does not disclose details like whether the original remains unchanged, permissions required, or potential side effects. With annotations providing baseline safety info, this is adequate but not rich.

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

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

A single sentence that is direct and complete. It conveys the core purpose without extraneous detail, making it easy to parse and understand.

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 at least hint at the return value, but it only says the result is an 'editable company copy' without specifying what is returned (e.g., the new copy's ID). It also omits whether the original is preserved, though that is implied by 'duplicate.' For a simple tool, this is minimally sufficient but leaves some 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 covers both parameters (art_direction_id and name) with descriptions, achieving 100% coverage. The description does not add any additional meaning about parameter usage beyond what the schema already 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 clearly states the action (duplicate), the resource (system or company ArtDirection), and the outcome (an editable company copy). This distinguishes it from sibling tools like create_art_direction or update_art_direction by focusing on the duplication aspect.

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

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

The description implies when to use this tool (when you want an editable company copy of an existing ArtDirection) but does not explicitly mention alternatives or exclude other tools. It lacks direct guidance such as 'use instead of create_art_direction when you want a copy based on an existing system or company ArtDirection.'

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the agent knows it is a safe calculation. The description adds no behavioral context beyond the name, such as whether the estimate is approximate or depends on current pricing. It does not contradict the annotations.

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

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

The description is a single, focused sentence with no extraneous words. It is front-loaded with the verb and object. While it is brief, this is not a flaw; it 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?

Despite having six parameters and no output schema, the description does not clarify what the tool returns (e.g., a numeric credit amount, a breakdown) or how the estimate is computed. The annotations cover safety but not functional expectations. This leaves the agent guessing about the tool's output.

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 100% coverage of all six parameters with descriptive details (e.g., operation enum values, duration constraints, generate_audio doubling cost). The description adds no additional parameter semantics, so the baseline score of 3 applies.

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

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

The description clearly states the tool's function: estimating credit cost for an operation, using the specific verb 'estimate' and resource 'credit cost'. It is distinct from sibling tools like get_user_credits and create_credit_checkout_session, which deal with balance and purchase rather than cost estimation. However, it lacks detail on the range of operation types covered.

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 guidance on when to use this tool versus alternatives. There is no mention of prerequisites, such as having an operation in mind, or exclusions like needing to check actual credit balance. Sibling tools are not referenced.

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

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

Annotations are all false (readOnlyHint: false, destructiveHint: false), so the description carries the disclosure burden. It explains the prerequisite and classification action but does not reveal side effects like whether it finalizes the garment, consumes handles, or is idempotent. Some scope constraints are added, but deeper behavior remains opaque.

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 the prerequisite ('Second step only'), and every sentence adds value: prerequisite, action, and exclusion. No fluff or redundancy.

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

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

Given no output schema, the description doesn't need to explain return values. It covers the two-step flow, the requirement for prepared/uploaded handles, the classification scope, and explicit non-uses. It could mention that it ultimately creates/updates garment records, but the schema's garments array implies this. Fairly complete for an agent.

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

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

Schema description coverage is 100% with detailed field explanations (e.g., upload_handle description, asset_kind enum, processing_mode). The description only restates the classification concept (full/detail front/back/side) without adding new parameter-level semantics beyond what the schema already provides. 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?

The description clearly states the tool's purpose: 'Second step only for local garment images already prepared with prepare_local_garment_upload' and 'Classify each upload_handle as a full/detail front/back/side asset.' It explicitly distinguishes itself from tools for ChatGPT attachments or public URLs, making it highly specific.

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 conditions: 'Second step only' and 'uploaded to every returned target.' It also includes a clear exclusion: 'Do not use this for ChatGPT attachments or arbitrary public URLs.' This effectively tells the agent when to use it versus alternatives.

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 behavioral context beyond the annotations, especially that traits are user-given facts and never guessed, and that the default is a bust identity anchor. The draft workflow also implies that results are image URLs that must be saved later, which is useful. It does not fully explain destructive or cost-related behavior, but destructiveHint already covers the safety signal.

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 front-loaded with purpose and stays relatively compact given the tool's complexity. Each sentence contributes either workflow guidance, policy clarification, or sibling routing. Minor redundancy exists because the default view and never-inferred rules are also reflected in parameter descriptions, but this does not significantly hurt readability.

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

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

For an 11-parameter tool with no output schema, the description provides a solid workflow, identifies the relevant sibling, and clarifies inference policy. It could more explicitly describe the return shape or when to prefer create_avatar_from_references or add_avatar_reference, but the core call-and-flow information an agent needs 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 100%, so the schema already documents each parameter. The description adds value by explaining the identity_reference_urls draft-flow semantics, emphasizing that traits are never guessed, and framing the default view as a clean identity anchor, which is not obvious from the schema alone.

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

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

The description states a specific action and resource: generating reusable avatar/model references through the Uwear creator path, with a clearly defined default view. It also distinguishes itself from related tools by naming build_avatar_prompt and save_generated_avatar as separate steps rather than the same action.

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

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

The description gives explicit when-to-use guidance: call build_avatar_prompt first only if the user needs help writing the description, otherwise pass wording directly. It also explains the draft multi-view workflow step by step, including when to pass identity_reference_urls and when to call save_generated_avatar.

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, covering the safety profile. The description adds the term 'selectable,' which suggests a filtering or state-related behavior not present in annotations, but it is vague. No additional details about not-found behavior or response format are provided.

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, concise sentence (7 words) that is immediately understandable. There is no fluff or redundant information, and the key information (get by ID) 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 simple get-by-ID tool with one parameter and strong annotations, the description is largely sufficient. However, the term 'selectable' introduces ambiguity about whether non-selectable ArtDirections are excluded, and without an output schema, the description does not clarify the return structure beyond implying the ArtDirection object. This leaves some context 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?

The input schema already fully describes the single parameter (art_direction_id with type and description). The description's 'by ID' reinforces the parameter's purpose but adds no new semantic detail. Baseline of 3 applies due to 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 the action (Get) and the resource (ArtDirection) with a specific scope (by ID). It distinguishes from list_art_directions by implying single retrieval, though it doesn't explicitly differentiate from other get_* tools. The word 'selectable' adds a minor qualifier but the core purpose 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?

No guidance is given on when to use this tool versus alternatives like list_art_directions or get_art_direction_authoring_job. The description only states what it does, not the context or exclusions. There is no mention of prerequisites or when to prefer this over other retrieval methods.

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 well beyond the annotations (readOnly, idempotent, non-destructive) by detailing what a done job includes (authored markdown, optional saved art_direction_id), what iteration jobs expose (source ID, expected revision, apply outcome), and what a failed job provides (per-source status, safe failure reason). This gives the agent a clear behavioral model for expected outputs and failure modes.

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

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

The description is compact and front-loaded, opening with the core purpose in one sentence. Each subsequent sentence adds distinct value (polling semantics, done job payload, iteration specifics, failure handling). No superfluous words 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?

Given the absence of an output schema, the description sufficiently explains return values and states: done vs failed, what each contains, and special cases for iteration jobs. It also covers the async polling pattern and save flag behavior, making the tool's behavior fully understandable for a complex async operation.

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

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

The schema already describes job_id with 100% coverage, but the description adds important context by clarifying that the job ID can come from either author_art_direction or iterate_art_direction, extending the schema's mention of only the former. This enriches the agent's understanding of valid inputs.

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

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

The description clearly states the tool's purpose: to read an asynchronous ArtDirection authoring job. It uses a specific verb ('Read') and resource ('ArtDirection authoring job'), and distinguishes itself from sibling tools like get_art_direction by focusing on polling job status rather than fetching a direct entity.

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: poll the job ID returned by author_art_direction or iterate_art_direction until done/failed. It names the source functions and describes polling behavior. However, it does not explicitly state when not to use this tool or mention alternatives like get_art_direction for direct retrieval, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds essential behavioral context: it loads 'unchanged,' rejects placeholder/guessed IDs, and is not for starting new shoots or editing. This goes beyond the annotation flags without contradicting them.

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

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

The description is four sentences, front-loaded with the core function, then usage rules, then exclusions. Every sentence adds necessary guidance with zero fluff or redundancy.

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

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

Despite having no output schema, the description fully covers the tool's purpose, constraints, and relationship to alternatives (update_brief). With one well-documented parameter and rich annotations, no critical information 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% and the schema parameter description already provides semantics: 'Real persisted brief ID to load unchanged. Do not use 0, guessed IDs...' The description reiterates these constraints but does not add significant new meaning beyond usage context, which is already covered by guidelines. 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 a specific verb+resource: 'Load an existing persisted brief unchanged by a real positive brief_id.' It clearly distinguishes from siblings by explicitly stating when to call update_brief instead of looping on get_brief.

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 explicit when-to-use conditions ('Only use when the user supplied that brief_id or after propose_brief/update_brief returned it') and when-not-to-use ('Never use this to start a new photoshoot' and 'call update_brief instead' for modifications). It names the alternative tool update_brief directly.

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 the operation as read-only, idempotent, and non-destructive. The description adds useful behavioral context by specifying exactly what it returns and that it is scoped to the authenticated connection, without contradicting the annotations.

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

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

The description is two sentences with no filler. The first sentence front-loads the core function, and the second adds the key usage context. 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 zero-parameter getter with rich annotations and no output schema, the description adequately explains both the return values and the operational context. Nothing critical is missing for an agent to decide when and 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 tool has zero parameters and the schema is fully self-documenting with an empty properties object. The description therefore has no parameter burden to carry, and a baseline of 4 for zero-parameter tools 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 states a specific verb ('Return') and resource ('profile ID and active company ID used by this authenticated MCP connection'), making it clear what the tool does. This distinguishes it from the many get_* siblings, which operate on different 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?

The description explicitly instructs when to call this tool: 'Use this before a paid operation when a release or audit must prove the connection is scoped to the intended Uwear account.' It does not explicitly state when not to use it or name alternatives, but no sibling appears to overlap with its purpose.

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, and destructiveHint=false, so safety profile is covered. The description adds no extra behavioral context (e.g., not-found behavior, return details), but with annotations present, the value added is limited. It 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?

One short sentence that is front-loaded and earns its place. No wasted words or redundant restating of the tool name.

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

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

The tool is a simple get-by-ID with one parameter and no output schema. Annotations cover the safety profile. The description plus schema is sufficient for an agent to invoke it correctly; no additional detail is essential.

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%: the single parameter garment_id is fully described as 'The garment ID to retrieve'. The description 'a specific garment by ID' adds no new semantic meaning beyond what the schema already provides, so 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 'Get a specific garment by ID' clearly states the verb (get), resource (garment), and singular scope (specific, by ID). It distinguishes this tool from siblings like list_garments, which retrieves multiple garments.

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 you need one garment by ID, but it does not explicitly state when to use this tool versus alternatives like list_garments or update_garment. No when-not-to-use or alternative names are provided, so it only meets the implied usage level.

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 readOnlyHint and idempotentHint annotations, the description reveals non-obvious behavior: 'They are display previews, not originals: url/download_url are originals, preview_url is the fallback link, and poster_url/thumbnail_url is a video poster.' It also warns against Markdown-embedding result URLs and mentions that raw payload is returned when available, providing significant context beyond 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 long (about six sentences) but each sentence provides necessary information for correct usage, such as URL semantics, ID handling, and confirmation-flow guidance. It is front-loaded with the purpose but the later section on confirmation clients could be separated for better scannability. Still, no sentence is wasted.

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 18-parameter tool with no output schema, the description thoroughly covers retrieval modes, result content (labeled ImageContent previews), URL differentiation, downstream ID usage, and date-filter examples. It addresses confirmation workflows and raw payload recovery, making it nearly self-sufficient for an agent to use this tool and understand its outputs.

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 covers all 18 parameters, so the baseline is 3. The description adds value by clarifying the generation_result_id vs generation_id usage and emphasizing that these integers are required for QA/edit/upscale/video commands. It also gives a semantic example for start_date/end_date, slightly exceeding what the schema 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 'Look up generation results by exact IDs, filters, or hybrid image/name/SKU search', clearly stating the action and resource. It further differentiates from siblings by explaining the distinction between generation_result_id (single result) and generation_id (list a job's results), which prevents confusion with get_generation_status or QA 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 tells when to use downstream tools: 'Confirmation-gated clients use propose_brief(commands=[...], execute_immediately=true) when the user asked to run now, update_brief for a complete command replacement, or confirm_brief(execute=true) for a visible brief.' It also provides clear guidance for using generation_result_id vs generation_id and gives a real-world example for start_date/end_date ('last week').

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, and the description adds substantial behavior beyond that: preview URLs are display-only fallbacks, failed jobs return safe error details, status can remain Created while queued, and UI model names map to specific model_slug values. No contradictions with annotations.

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

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

The description is front-loaded with a clear one-line purpose and then packs dense, useful details about previews, error types, and status behavior. It is somewhat long and repeats the model_slug mapping already present in the schema, but each sentence still contributes operational value.

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 single-parameter status tool with no output schema, the description is complete: it covers status transitions, returned fields, failure payloads, preview URL semantics, and polling guidance. An agent has enough context to invoke the tool correctly and interpret its response.

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 generation_id parameter, so the schema already documents the parameter. The description does not add new meaning about generation_id itself; it lists return fields and behaviors, which is useful but not parameter-specific. 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?

The description opens with a specific verb and resource: 'Check generation job status.' It clearly distinguishes this status-checking tool from result-fetching siblings like get_generation_results by focusing on job progression and return metadata rather than final outputs.

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 practical usage guidance: avoid tight polling loops while status remains Created, use completed previews directly, and never Markdown-embed result URLs. It does not explicitly name alternative tools or give exclusion criteria, but the intended usage context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description only needs to add context. It does by noting 'grouped by type' and the no-UI workflow context, which informs expected behavior. It does not contradict annotations and adds some value beyond them.

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

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

Two crisp sentences: the first states the core function, the second provides workflow context. No wasted words, information is front-loaded and immediately relevant.

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 lookup with two parameters and rich sibling context, the description covers the workflow and return type sufficiently. It could elaborate on the exact grouping structure, but the absence of an output schema is partially mitigated by the description's clarity.

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 descriptions for both parameters, including allowed values for item_types. The description does not add significant meaning beyond the schema, so 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 uses specific verb+resource ('Get all item IDs tagged with a specific tag, grouped by type'), clearly distinguishing it from sibling tools like list_tags or propose_brief. The workflow reference further clarifies its unique role.

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 states when to use ('Use after list_tags for no-UI MCP requests'), provides a concrete example ('use my clothes tagged summer26'), and names an alternative ('instead of opening request_user_context'), giving strong 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the context that the location is 'reusable' and a 'scene reference', but does not disclose any additional behavioral traits such as error handling or response details.

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, front-loaded sentence that communicates exactly what the tool does with no wasted words. Every word adds value.

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 single-parameter read operation with strong annotations, the description is nearly sufficient. It clearly identifies the resource and method, though a brief note about the return value would make it 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?

Schema coverage is 100% and the only parameter 'location_id' is clearly described in the schema. The description adds no new parameter information beyond 'by ID', so it does not elevate above the baseline for full 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 uses a specific verb 'Get' with a clear resource 'reusable location/scene reference' and method 'by ID', making its function unambiguous. It naturally distinguishes itself from sibling tools like list_locations and create_location by implying a single item lookup.

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 (retrieve a location when you have its ID) but provides no explicit when-to-use guidance or mention of alternatives like list_locations for browsing. There is no guidance on when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral context beyond annotations by stating that the response includes the outfit's member garments, which is valuable given there is no output schema.

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

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

A single sentence delivers the essential message with no filler. The subject and action are front-loaded, and 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?

For a simple single-ID read operation with strong annotations and full schema coverage, the description is complete. It clarifies the return composition ('member garments'), which is the main missing piece in the absence of an output schema.

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

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

Schema description coverage is 100% and the outfit_id parameter is already well-documented with type, minimum, and meaning. The tool description adds no additional parameter semantics, 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?

The description uses a specific verb ('Get') and resource ('one saved outfit by ID') with an added qualifier ('including its member garments') that distinguishes it from list_outfits and get_garment. The scope is precise and immediately understandable.

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 clearly implies this tool is for retrieving a single saved outfit when the ID is known, which differentiates it from sibling tools like list_outfits. It provides clear context but does not explicitly name alternatives or state when-not-to-use conditions.

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, and destructiveHint=false, so the safety profile is covered. The description adds the canonical-company scope and the two lookup paths, but doesn't disclose return shape, error behavior, or the exact-one-identifier expectation.

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

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

Two sentences, front-loaded with the primary action and identifier modes, followed by the one conditional parameter note. No filler or repetition.

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

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

With only three optional parameters and rich schema descriptions, the description is mostly sufficient, but it does not state that exactly one of template_id or share_code is needed, nor what a successful load returns. Since there is no output schema, a bit more return-value clarity would improve completeness.

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 when expected_template_kind matters but adds no new meaning beyond the schema's own descriptions of share_code, template_id, and the expected-kind mismatch behavior.

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

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

The description states a specific verb ('Load'), a specific resource ('one canonical company template'), and two concrete identifier modes (ID or public t-xxxx share code). This clearly separates it from siblings like list_templates, save_template, and delete_template.

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 explicitly tells the caller when to supply expected_template_kind ('when the caller requires a generation_preset or batch_workflow'). It doesn't explicitly name alternative tools or exclusion cases, but the single-template load intent is clear enough for tool selection among the siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the context that it retrieves the 'current' balance for the user, which is useful but minimal. It 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, clear sentence with no wasted words. It is immediately understandable and well-structured.

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 no parameters and rich annotations, the description sufficiently communicates the operation. It does not describe the return format, but given the low complexity, this is an acceptable gap.

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

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

The tool has zero parameters and schema coverage is trivially 100%, so the baseline is 4. The description adds no parameter details because there are none to describe.

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 ('Get') and resource ('user's current credit balance'), which distinguishes it from related tools such as create_credit_checkout_session and estimate_cost. It is slightly more specific than the title, though it does not explicitly mention 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?

No guidance is provided about when to use this tool versus alternatives. The description does not mention any exclusions or context for use, leaving the agent to infer from the name alone.

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

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

The description discloses important behavioral traits beyond the annotations: it is a queued/asynchronous operation, it preserves existing authoring references automatically, save=true includes stale-edit protection, and system ArtDirections have draft-only restrictions. This adds significant context that the annotations alone do not 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 four sentences, front-loaded with the primary action, and every sentence contributes distinct value: queueing behavior, automatic references, save semantics, system restriction, and polling instruction. No wasted words or redundancy 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?

Given the absence of an output schema, the description appropriately directs users to poll get_art_direction_authoring_job for the result, making the async flow complete. It also covers the key edge cases (system drafts only, stale-edit protection) and the distinction between draft and saved updates, making the tool's behavior clear without needing more details.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds parameter-specific meaning by clarifying the save=true/false semantics (draft vs. permanent update) and the system ArtDirection draft-only restriction. It also clarifies that existing references are included automatically, which supplements the optional nature of sources and reference_image_attachments parameters.

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

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

The description clearly states the tool queues a feedback-driven revision of an existing ArtDirection without resending markdown, which is a specific verb+resource action. It distinguishes itself from siblings like create_art_direction and update_art_direction by emphasizing the feedback-driven iterative nature and automatic inclusion of existing references.

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 usage guidance is provided: use save=false for a draft, save=true to update the same company ArtDirection with stale-edit protection, and system ArtDirections support drafts only. It also directs the user to poll get_art_direction_authoring_job for results, clarifying the expected follow-up workflow.

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, so the safety profile is covered. The description adds behavioral context about the returned format (compact summaries), inclusion of system and company ArtDirections, and query behavior for natural-language requests, which is useful beyond 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 sentences, front-loaded with the primary function and using each sentence for distinct guidance: output scope, query usage, and follow-up action. 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?

The tool is a simple list operation with optional parameters and no output schema, but the description covers what is returned (compact summaries), what is included, how to use it in the workflow, and where to go for full details. It is fully contextualized within its 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?

Schema coverage is 100%, so the schema already documents page, limit, and query. The description adds slight nuance by explaining query can match exact names and natural-language creative requests, but this largely mirrors the schema's 'hybrid search' description, so a baseline score 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 it lists selectable ArtDirections as compact summaries, specifying the scope (visible system plus company ArtDirections). This distinguishes it from get_art_direction, which is referenced for full documents.

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 explicitly positions the tool as the catalog step before choosing an art_direction_id for a brief and advises a fallback to the user's phrase if no match. It also directs users to get_art_direction for full markdown, providing clear when-to-use and alternative 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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description goes beyond by explaining the domain semantics (avatars vs. AI models) and the hybrid search behavior, adding useful context that annotations do not 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?

Three focused sentences, each adding value: purpose, distinction from sibling, and key parameter guidance. No redundant phrasing or unnecessary detail.

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

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

For a list tool with 9 optional params and no output schema, the description covers the essential context: what avatars are, the alternative tool, and the critical include_image_url scenario. Pagination and date filters are left to the schema, which is sufficient given the tool's simplicity. It could mention return format, but that's not critical here.

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

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

Schema coverage is 100%, so the baseline is 3. The description echoes the query parameter's hybrid search behavior and the include_image_url usage, but these are already described in the schema. It adds minimal new information beyond what structured fields provide.

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 'List the user's avatars', a clear verb+resource statement. It further clarifies that avatars are the reusable people/models/mannequins in fashion terms, and explicitly distinguishes from list_models for AI engines, which differentiates it from a likely sibling.

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 guidance: 'not the AI engines — for those, use list_models' directly names the alternative. It also gives a concrete usage trigger: 'Set include_image_url=true when the avatar image itself is needed.' This tells the agent when to use the tool and how to configure a key parameter.

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

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds behavioral context by distinguishing structured filtering from hybrid name/SKU/metadata/image-attribute search, which is not obvious from the annotations alone. 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 a single sentence, front-loaded with the verb and object, and every clause contributes meaningful scope or mode information. There is no redundancy or unnecessary detail.

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

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

For a read-only listing tool with 10 fully described optional parameters and no required inputs, the description covers core intent and query behavior well. It does not describe the output shape, but the list semantics and schema defaults make invocation predictable enough.

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 covers 100% of parameters with rich descriptions, so the baseline is 3. The description's 'hybrid name/SKU/metadata/image-attribute search' largely paraphrases the query parameter's existing description and adds little new parameter-level meaning.

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

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

The description states the specific verb 'List', the resource 'user's garments', and the two operating modes: structured filters and hybrid query across name/SKU/metadata/image-attribute. This clearly distinguishes it from sibling list tools like list_models/list_outfits and from get_garment.

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 makes clear that this tool is for listing a user's own garments and explains the two call styles: structured filters or a hybrid query. It does not explicitly name sibling alternatives or exclusion conditions, so it falls just short of a 5.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful context about the data being 'reusable location/scene reference images' and the user intent, but it does not disclose additional behavioral traits like return format, pagination behavior, or any edge cases beyond what annotations 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 with no unnecessary words. The description front-loads the main action and resource, then provides filter details and a use case. 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?

Despite having 9 optional parameters and no output schema, the description is adequate for a list tool: it names the resource, the filter dimensions, and the primary use case. The comprehensive schema covers parameter semantics. It could be slightly more complete by mentioning the return type (e.g., paginated list of location references), but the current coverage is solid.

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 having a detailed description. The description's summary of filters ('IDs, tags, date range, and sort') offers a high-level abstraction but does not add meaning 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 verb 'List' and the specific resource 'reusable location/scene reference images'. It enumerates filter types (IDs, tags, date range, sort) and gives a concrete use case ('pick a saved background/location reference'), which distinguishes it from sibling tools like get_location or create_location.

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 'Use when the user wants to pick a saved background/location reference for a generation' provides clear context on when to invoke this tool. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of full 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond annotations by specifying the returned information: credit costs, capability limits, and model-specific production guidance. This helps the agent know what to expect from the call.

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

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

The description is two sentences with no filler. It front-loads the core purpose, then efficiently adds disambiguation and alternative routing. 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 simple, one-parameter, read-only list tool with full schema coverage and clear annotations, the description is complete. It tells the agent what the tool returns, how to categorize models, and which sibling to use instead. No critical information 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?

The schema already documents the only parameter, model_type, with a clear description covering its allowed values ('generation, edit, upscale, video, backdrop'), so schema coverage is 100%. The description adds context about model categories but does not need to repeat the schema details.

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: 'List available AI generation models... by type', and explicitly distinguishes these AI models from human models/avatars. It also names the sibling tool (list_avatars) for the alternative, making the tool's purpose unmistakable.

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 explicit usage guidance: this tool is for AI generation models, not human models/avatars, and directs users to list_avatars for those. This is a clear when-to-use vs alternative distinction.

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, and destrutiveHint=false, so the safety profile is covered. The description adds that the listing is user-scoped and that outfits are saved combinations, but does not disclose pagination behavior, default filter semantics, or return shape. Given annotation coverage, this is adequate but not rich.

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 compact sentence that leads with the core action and usefully clarifies what an outfit is. Every clause earns its place; there is no filler or redundancy.

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

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

For a read-only list operation with full schema descriptions, annotations, and a clear resource scope, this description is almost complete. It would be fully complete with an explicit pointer to the single-outfit sibling or a note about pagination defaults, but those are already inferable from the 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 every parameter is already documented with defaults and meaning. The description only summarizes parameter categories (garment IDs, active status, date range, query) and adds no new semantic detail beyond the schema. 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?

Clear verb+resource: 'List user's outfits' and defines outfits as 'saved garment combinations'. The filtering summary helps identify the operation, but it does not explicitly differentiate itself from siblings like get_outfit or propose_outfits, so it stops 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 phrase 'List user's outfits' and the filter list imply this is the bulk retrieval tool for saved outfits, and the user-scoped wording signals scope. However, there is no explicit when-to-use versus alternatives, such as using get_outfit for a single outfit or propose_outfits for generated suggestions.

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, destructiveHint=false, so the safety profile is clear. The description adds behavioral context by outlining a typical workflow (resolving tag names to IDs) and directing to follow-up tools, which goes beyond annotation coverage.

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 core purpose, and immediately followed by actionable usage guidance. No wasted words.

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

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

For a simple list tool with no output schema, the description fully covers what the tool does, why it's useful (tag resolution), and how to use its output. No gaps remain.

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 baseline for 0 params is 4 because there are no parameter semantics to explain. The description appropriately focuses on the tool's purpose and usage.

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 available tags for the user's company.' This is a specific verb+resource+scope, and it distinguishes from siblings by explaining that this is the tag lookup tool used before other operations.

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 when-to-use guidance is provided: 'Use this to resolve user-provided tag names... before selecting garments, outfits, models, files, generations, or locations.' It also gives a concrete alternative: 'For no-UI MCP flows, find the tag ID here, then call get_items_by_tag or the relevant list_* tool with tag_ids.'

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 carry readOnlyHint=true and idempotentHint=true, and the description adds genuinely new behavioral context beyond them: templates persist but never execute generations, and 'Demo — …' templates are worked examples of the canonical command language. Nothing contradicts the annotations, which support the read-only framing.

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

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

Two sentences with the purpose and filter axes front-loaded in the first, followed by a compact behavioral caveat and a concrete next-step pointer. Every clause earns its place; there is no filler or repetition of schema 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 six-optional-parameter list operation with full schema coverage and safety-carrying annotations, the description covers the object's nature, all filter dimensions, the non-execution behavior, and the natural follow-up via get_template. The only shortfall is the absence of return-shape guidance, which carries slightly more weight because no output schema exists.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters in detail, including the owner-only visibility rule and the writable/read-only enum distinction. The description adds only a light summary of the filter axes (kind, scope, use case, share code) that maps to schema parameters without deepening their semantics — 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 states a specific verb and resource — 'list canonical company templates' — and enumerates the filter dimensions (kind, scope, use case, share code). It distinguishes itself from siblings by framing templates as persisted canonical commands rather than executable or writable records, and implicitly differentiates from get_template which reads a single template.

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 routes follow-up behavior ('read one with get_template before authoring a first brief or workflow') and clarifies that templates 'do not execute generations', steering an agent toward generation tools when execution is needed. It does not, however, enumerate exclusions against other browsing or search siblings such as search_uwear_library.

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 non-read-only, non-idempotent, non-destructive mutation. The description adds useful context about app-only availability and session scoping, but does not disclose potential duplicate behavior or other side effects beyond what annotations imply.

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 front-loaded sentence that conveys all essential information without waste.

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

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

For a simple one-parameter mutation tool with no output schema, the description provides key context (app-only, session-scoped, append behavior) and is sufficiently complete. It does not describe return values, but that is not required given the absence of an output schema.

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

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

Schema coverage is 100% (the single parameter has a description), so baseline is 3. The description adds no extra meaning beyond 'append items' which merely restates the parameter name 'context_items'.

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 ('append'), the resource ('Uwear Shoot Board'), and the scope ('session-scoped'), which distinguishes it from sibling tools like mcp_replace_context (replace) and mcp_clear_context (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 term 'append' implies adding to an existing board, subtly distinguishing from replace/clear siblings, but there is no explicit guidance about when to use this tool versus alternatives or 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 indicate destructiveHint=true and idempotentHint=true. The description adds behavioral value by explaining the all-or-one-type clearing behavior and the 'App-only' constraint. It does not contradict annotations and adds meaningful context beyond what the annotations 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?

The description is extremely concise—a single sentence that conveys the essential scope and behavior. Every word adds value, and it is front-loaded with the action and resource.

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

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

For a simple tool with one optional parameter, no output schema, and strong annotations, the description is complete. It fully covers the tool's behavior (clear all or specific type) and the app-only constraint, leaving no significant gaps.

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

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

Schema description coverage is 100%; the parameter 'type' is well-documented with an enum and description 'Context type to remove; omit to clear the entire Shoot Board.' The description's mention of 'one context type' adds no new meaning beyond the schema, so 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 tool's function: 'clear all session context items, or only one context type.' It uses a specific verb (clear) and resource (session context items/Shoot Board), and it distinguishes from sibling tools like mcp_add_context and mcp_replace_context by focusing on removal.

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: it's app-only and clears either all context items or a specific type. It implies when to use it (when clearing context is needed), but it does not explicitly mention alternatives or when-not-to-use scenarios. This is clear enough for the simple use case.

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 context about being app-only and user-initiated, but does not disclose the return format or detailed side effects beyond creating a checkout URL. Annotations already cover the safety profile (readOnlyHint false, destructiveHint false), so the description adds moderate 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 two sentences, front-loaded with purpose, and the second sentence adds a usage constraint. Every word earns its place with no 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?

The tool is simple (4 optional params, no output schema). The description explains purpose and usage context well. It could explicitly state the return value (the checkout URL) but that is implied by 'create a hosted Stripe Checkout URL.'

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%, and the tool description does not add meaning beyond what the schema already provides for the four optional parameters. 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 purpose: 'create a hosted Stripe Checkout URL for buying Uwear credits.' It uses a specific verb ('create') and resource, and distinguishes it from sibling tools like get_user_credits and estimate_cost.

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 provides usage context: 'App-only' and 'Hidden from the host LLM so photoshoot planning does not drift into billing unless the user presses the plus button.' This gives a clear when-not-to-use condition. However, it does not name alternative tools for credit checking or estimation.

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

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

Beyond annotations (destructiveHint=true), the description reveals that the tool 'spends credits' and is 'hidden from host LLMs,' adding cost and access context. It also discloses the return behavior: 'Returns the generation_id to poll via get_generation_status.' This complements the annotations without contradicting them.

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

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

Three sentences, each earning its place: the action, the credit/access constraint, and the return value. No redundant detail or padding. The most important operational fact (app-only) 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?

Despite having no output schema, the description explains the return value (generation_id) and how to follow up (get_generation_status). The credit spend and app-only access are covered. All 4 required parameters are described in the schema, so the description is complete for this 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 100%, so the baseline is 3. The description adds little beyond the schema: it references 'user-confirmed montage clips' but does not elaborate on fit_mode, aspect_ratio, or base_resolution. The schema already documents these, so the description does not need to.

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

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

The description states a specific verb and resource: 'export the user-confirmed montage clips as a stitched video.' It clearly distinguishes from siblings like propose_montage and update_montage_proposal by focusing on the final export action. The phrase 'stitched video' specifies the output type.

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

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

The description explicitly states when to use it: 'App-only' and 'the MCP iframe calls this after the user presses Export on the MontageProposal card.' It also excludes host LLMs ('hidden from host LLMs') and mentions the credit cost, which is a key constraint. This effectively differentiates it from proposal-generation tools.

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

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

The description adds behavior beyond annotations: it spends credits, is app-only/hidden from host LLMs, queues the generation, and returns a generation_id to poll. This complements the destructiveHint annotation without contradicting it.

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

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

Three sentences with no wasted words. The most important information is front-loaded, followed by the credit-spending caveat and the return value in a logically ordered way.

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 queue-style tool with 9 schema-documented parameters, the description sufficiently explains purpose, usage restrictions, side effects, and how to follow up. The lack of an output schema is mitigated by explicitly mentioning the generation_id and the polling endpoint.

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 each parameter already has descriptive text. The description adds no parameter-specific meaning beyond the general image-to-video context, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool queues an image-to-video generation for a montage clip. It names the specific action ('queue'), the resource ('montage clip'), and scope ('App-only'), distinguishing it from sibling tools like propose_montage and mcp_export_montage.

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 explicitly says when to use it: the montage editor calls this when the user presses Generate on a draft clip, and it is hidden from host LLMs, providing a clear when-not. It does not name alternative tools, but the context is strong.

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

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

Annotations already declare read-only and idempotent behavior, so the description only needs to add extra context. It adds 'App-only' and 'session-scoped' constraints, which are useful, but 'hydrate' remains vague about whether the tool returns data, initializes the board, or both.

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 with no wasted words, but it is arguably too terse. The term 'hydrate' could be replaced with more explicit language, yet the structure is clean and 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?

With no output schema, the description must convey what the agent should expect. It does not explain what a 'Shoot Board' is or what 'hydrate' returns or does, leaving significant ambiguity about the tool's actual effect and return value.

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, so there is no parameter documentation burden. The baseline of 4 applies since the description doesn't need to compensate for schema gaps.

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

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

The title 'Get Shoot Board' clarifies the retrieval intent, and the description identifies the resource ('Uwear Shoot Board') and scope ('session-scoped'). The verb 'hydrate' is somewhat non-standard but still conveys loading the board. It is distinguishable from mutation siblings like mcp_add_context, though 'hydrate' adds jargon.

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?

No guidance is given on when to use this tool vs alternatives such as request_user_context or other getters. The 'App-only' label is a constraint, not a usage trigger, and no exclusions or alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the 'App-only' scope and the workspace files tab, but does not provide additional behavioral details like pagination behavior or return format. 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, concise sentence that is front-loaded with the core action and includes the necessary context ('App-only', 'workspace files tab'). No wasted words.

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

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

This is a simple read-only list tool with two optional parameters and no output schema. The description states what it lists but does not describe the return value structure or pagination defaults. Given the low complexity, a brief description is mostly sufficient, but a little more detail (e.g., what fields/objects are returned) would be helpful.

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% (both 'page' and 'limit' have descriptions). The tool description adds no additional meaning for the parameters, 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 specifies the verb 'list' and the resource 'uploaded files', with a clear context ('Uwear MCP workspace files tab'). It distinguishes from sibling list tools by focusing on 'uploaded files' rather than garments, avatars, etc. However, it could be slightly more explicit about what constitutes 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?

The description does not provide any explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions. The 'App-only' prefix is a constraint but not a usage guideline. It gives no indication of when to prefer this over other list_* tools.

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

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

Annotations already convey destructive and idempotent behavior. The description adds 'session-scoped' and 'App-only', which narrow the scope and provide context beyond what annotations state. This is meaningful incremental value, though it does not detail side effects.

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 action and includes key constraints. It contains no filler and every word contributes meaning.

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

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

The description, combined with the schema's parameter descriptions, provides sufficient clarity for an agent to understand the tool's purpose, scope, and parameter semantics. The only minor gap is the undefined meaning of 'App-only', but overall it is complete for a replace tool with no 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% and both parameters have detailed descriptions, including the precedence relationship between context_items and context_state. The tool description adds no parameter-specific info, so the schema carries the burden, resulting in baseline 3.

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

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

The description clearly states the action ('replace') and the resource ('session-scoped Uwear Shoot Board items'). This distinguishes it from sibling tools like mcp_add_context and mcp_clear_context, which have different operations.

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 replacement semantics compared to add/clear but does not explicitly name alternatives or provide exclusion criteria. The 'App-only' hint offers some context but does not fully guide an agent on when to select this tool over its siblings.

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

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

Annotations indicate readOnlyHint=false and idempotentHint=false, which align with the write behavior. The description adds context that saves a 'child generation result' and is 'App-only,' clarifying the data model and invocation scope. It could mention return behavior, but annotations cover safety traits adequately.

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 tightly worded sentences immediately establish the tool's restricted audience and purpose. No wasted words; every element contributes essential context.

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 intentionally hidden from host LLMs, the description provides sufficient context for an agent to recognize it as internal. Schema covers required parameters, and the description clarifies the triggering flow. Minor gap: no return value or error behavior described, but given the 'App-only' designation, this is less critical.

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 covers all 5 parameters with descriptions, so baseline is 3. The description doesn't add new parameter-level information beyond what's in the schema, though it gives context for image_base64 and parent_generation_result_id through 'user-edited image' and 'child generation result.'

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: 'save a user-edited image from the shared ImageDetail retouch editor as a child generation result.' It uses a specific verb and resource, and the 'child generation result' distinguishes it from sibling save tools like save_generated_avatar.

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 states when to use: 'after the user presses Save.' Also clearly excludes host LLMs with 'Hidden from host LLMs; the MCP iframe calls this,' providing strong context for invocation.

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 key behavioral traits beyond the annotations: the returned form fields and file_field must be used, local paths must never be sent to Uwear, and a follow-up call is required. This adds essential context about the two-step protocol and response handling, compensating for the lack of an output schema.

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

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

Every sentence in the description serves a distinct purpose: scoping, prerequisites, execution details, security constraint, exclusions, and next-step instruction. It is dense yet efficient, with no redundant or filler content, and the key action 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?

Given the tool's complexity (two-step upload process) and the absence of an output schema, the description is remarkably complete. It tells the agent exactly what to do with the response, what to avoid, and what to call next, covering all necessary context for successful invocation.

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 comprehensive descriptions for each parameter (file_name, content_type, content_length) with constraints like max length and MIME type enums. The description adds no new parameter-level meaning—it only restates the local path rule already embedded in the schema—so the baseline of 3 for high schema coverage 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 role as the first step for uploading garment images from the host's local filesystem, using specific verbs like 'prepare' and identifying the resource. It also differentiates from sibling upload tools by explicitly excluding ChatGPT attachments and public URLs, making its purpose unambiguous.

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

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

The description provides explicit conditions for use: only when the host can read local files and perform direct multipart HTTP uploads. It also states exclusions ('Do not use this for ChatGPT attachments or existing public URLs') and directs the agent to call finish_local_garment_upload afterward, offering clear 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 declare destructiveHint=true but do not explain the mutation semantics. The description ranks as 4, not 3, because it discloses a rich set of non-obvious behaviors beyond the annotations: the error remediation for video_garment_view_not_attached, the relationship between execute_immediately flag and user intent, the constraint not to mix reference_attachments with img_ref_urls, and the persistence of commands/plans without translation. These add real behavioral context absent from annotations. It loses a point because it does not explain what 'destructive' means for a propose operation (a proposal being created is technically a create, but annotations mark it destructive, likely because it overwrites a draft).

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 packed with many important constraints but is a single dense paragraph. It front-loads the core purpose but then floods the agent with multiple instructions in rapid succession. Sentences like the video asset rule, the remediation, and the mixing prohibition are all valuable but arranged without clear hierarchy or separation. It is appropriately sized given the complexity but would benefit from bulleting or bolding key constraints. Not under-specified, but poorly structured for the amount of 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 tool with 3 parameters, one required, and no output schema, the description is comprehensive. It covers the required source references, the creative_context requirement for photoshoots, the execute_immediately rule, the video-attachment edge case with its remediation, and routing to update_brief. It is incomplete only in that it does not describe what the returned BriefProposal looks like (no output schema exists), but the description says 'Create a Uwear BriefProposal' and the remediation hints the response contains a field, so the agent can infer. Given the nested complexity of GenerationIntent, it does not describe every prompt-writing nuance here, but the schema's rich per-field descriptions carry that burden.

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 meaningful guidance beyond the schema parameters: for commands it clarifies the 'MCP-safe GenerationIntent fields' and the need for durable source IDs; for creative_context it emphasizes explaining art direction after proposing and requiring it for photoshoots; for execute_immediately it states the condition 'only when the user explicitly asks to run now,' which is a strict constraint not fully explicit in the schema. This is above the baseline but not a 5 because the description does not walk through each field of the nested GenerationIntent in detail (though the schema already does that with rich descriptions).

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

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

The description states a specific verb ('Create a Uwear BriefProposal') and a concrete resource ('from canonical generation commands'). It distinguishes this from update_brief by naming it as the tool for changes to a visible brief. However, it doesn't explicitly contrast with the many sibling tools like propose_outfits or propose_montage, which are also proposal-creation tools, though their outputs differ.

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

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

The description explicitly states when to use this tool ('Create a Uwear BriefProposal'), and provides clear exclusions: 'For changes to a visible brief, call update_brief with the complete replacement command list.' It also states that 'Webhook callback configuration is API-only,' telling the agent this tool cannot do that. It gives the key routing rule to the sibling update_brief, covering the primary 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 adds substantial behavioral context beyond the annotations: it clarifies that this tool only PROPOSES a montage for user review (not an actual export), that the user can edit/generate/export later, and that export is free while video generation costs credits. It also details how various parameters affect behavior (trim, generation, speed/mute). With annotations already declaring read-only and idempotent, the description enriches the agent's understanding of the propose-first workflow and cost implications.

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 long but every sentence earns its place. It is front-loaded with the critical scoping statement ('ONLY for video montage...'), then systematically covers exclusions, the proposal workflow, per-item semantics, and cost behavior. The structure flows logically from when-to-use to how-to-invoke, and there is no redundant 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 complex (nested MontageItemInput with 13 sub-properties, mixed video/image handling), yet the description covers all major aspects: item types, required fields, trim semantics, duration handling for image vs video, audio generation, aspect ratio, resolution, credit costs, and the post-proposal flow. The absence of an output schema is compensated by explaining the proposal-review-confirm sequence. This is as complete as one could expect for such a 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?

Even though schema coverage is 100%, the description adds meaningfully beyond the schema: it explains how to interpret user requests like '3 seconds each' into setting target_duration: 3 on every item, instructs to tailor per-image motion prompts and avoid generic repeated prompts, and advises inspecting the image with view_image when motion isn't specified. These are practical parameter-usage rules that go beyond the raw field descriptions.

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 sole purpose: video montage/stitching/export workflows, and that it PROPOSES a montage for user review. It explicitly differentiates from sibling tools like propose_brief and mcp_export_montage, and enumerates the exact trigger phrases ('create a montage', 'stitch clips', 'make a reel', etc.). This is a specific verb+resource with strong 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 provides explicit when-to-use guidance, including exact user request patterns, and equally explicit when-not-to-use exclusions (photoshoots, lookbooks, product shoots) with the correct alternative path ('request_user_context followed by propose_brief/update_brief'). It also warns against calling the tool merely because images exist in context, and clarifies that photoshoots must first be proposed as a BriefProposal. This is textbook 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?

Annotations declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds behavioral value by disclosing return contents ('candidate titles, clothing_item_ids, and short rationales') and the correct follow-up action, which are not present in annotations. It doesn't contradict any annotations.

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

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

Two sentences with no redundant phrases. The first sentence introduces the tool's core purpose, and the second provides return details and workflow. Every word contributes essential information, making it efficiently 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?

The description covers the tool's purpose, return payload, and the necessary next step (calling create_outfit_from_garment_ids). Since there is no output schema, describing return contents is essential and handled well. It doesn't detail edge cases or advanced behaviors, but those are unlikely needed for a straightforward proposal tool.

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

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

Schema coverage is 100%, with all three parameters (clothing_item_ids, max_outfits, instructions) already described in the input schema. The description adds no additional parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'use Uwear's outfit proposer to create styled outfit combinations from selected garments.' It identifies the specific resource (outfit proposals) and action (propose), and distinguishes itself from sibling tools like create_outfit_from_garment_ids by explicitly reserving that tool for a later saving step.

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

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

The description provides clear usage context: it tells the agent to call this tool to generate proposals and to call create_outfit_from_garment_ids only after the user chooses one. It doesn't explicitly list alternative tools or say when not to use it, but the workflow guidance is strong enough to guide tool selection.

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 provide destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds valuable context about credit costs (1 credit per result, no charge for already-completed rows) and that 'Retry generations can cost additional generation credits.' It also notes the tool is 'built for scale' and clarifies behavior for large batches. While it doesn't explicitly state destructive outcomes, the credit/retry details give additional transparency beyond 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 longer than typical but every sentence carries information: purpose, usage triggers, exclusions, workflow, costs, scale guidance. It is front-loaded with the core purpose and remains organized and scannable. A slight deduction for being a bit verbose, but it earns its length.

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?

No output schema exists, so the description should hint at expected outcomes. It does this indirectly by directing the user to call read_generation_result_qa afterward, implying the tool queues QA rather than returning results. It also covers costs, retries, scale, and when to avoid auto-invocation. Missing an explicit statement of what the tool returns (e.g., queue status or IDs), but the follow-up instruction mitigates this gap.

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%: both generation_result_ids and max_qa_retries have descriptions that already mention credit costs and retry implications. The tool description repeats those cost mentions but does not add new semantic meaning beyond the schema. Since schema does the heavy lifting, 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 states it is the 'Default tool for generation-result QA' with a specific verb (queue/run QA) and resource (generation results). It clearly distinguishes itself from view_image by explicitly forbidding substitution unless the user asks for manual visual critique. This is a specific verb+resource with 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 provides explicit when-to-use criteria ('whenever the user asks to QA, quality check, validate, review, inspect for defects, approve/reject, or assess already-created generation results'), a clear workflow ('First identify the numeric generation_result_ids, then call this tool, then call read_generation_result_qa'), and explicit exclusions ('do not substitute view_image', 'do not queue QA on your own initiative' for small batches). This fully addresses when and when not to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds value by explaining the tool returns structured QA decision and issues, and advising the agent to summarize rather than give a manual opinion. This extra context about output content and expected behavior goes beyond annotations.

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

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

The description is two sentences, front-loaded with the verb 'Read' and the resource. Every clause provides useful information: purpose, sequencing, and usage guidance. No waste or redundancy.

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

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

For a simple one-parameter read-only tool, the description covers purpose, when to call, what to return, and how to handle the result. Annotations cover safety, and schema covers parameters. No output schema is needed because the description indicates structured data and summarization advice. Complete enough for an agent to select and invoke correctly.

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

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

Schema description coverage is 100% for the single parameter generation_result_ids, with clear description. The tool description does not add significant parameter detail, but the schema already fully describes what the parameter means. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the tool reads official Uwear QA status, decision, and structured QA JSON for existing generation results. It distinguishes itself from siblings by emphasizing 'official' and 'structured' data, and explicitly contrasts with view_image, making the purpose specific and non-ambiguous.

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: 'Call this after queue_generation_result_qa when the user asks to QA/check/validate/review generated outputs' and instructs to 'summarize the structured decision and issues, not a manual view_image opinion.' This clearly tells when to use it and what not to do, differentiating it from alternatives.

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 and idempotentHint, but the description adds crucial behavioral context: 'BLOCKS until the user confirms their selection.' It also warns against telling users to drag assets into chat and advises to skip model requests when avatars=0. 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 lengthy but every sentence serves a purpose: condition, behavior, exclusions, alternatives, and special cases. It is front-loaded with the primary purpose and subsequent guidance is logically organized. It earns its length.

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 no output schema and the tool's complexity, the description is remarkably complete. It covers when to call, blocking behavior, no-UI alternatives, fallback upload procedures, and avatar handling. This is more than sufficient for an agent to decide and invoke the tool correctly.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds context about expected_types by explaining when to request models (optional, only if specific person is wanted) and mentions 'garment/outfit IDs or textual selectors' which indirectly relates to prompt construction. This goes slightly beyond the schema.

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

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

The description clearly states this is the 'FIRST tool to call for a new photoshoot' when the user hasn't supplied asset IDs or selectors. It specifies the action: 'Opens the MCP app/gallery so the user can choose assets, add them to the Shoot Board, and press Confirm context.' This distinguishes it from sibling tools by explicitly withholding it when a no-UI path can resolve the 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?

The description provides explicit criteria for when to use this tool ('only when the user has not supplied garment/outfit IDs or textual selectors') and when not to use it ('Do not use this when a no-UI path can resolve the request'). It even names alternatives like list_tags/get_items_by_tag/list_garments and upload_garment_from_chat_file, plus avatar fallback options.

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

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

Annotations are all false, so the description carries the disclosure burden. It adds meaningful behavioral context: each result fills a slot recorded in avatar_creator.view metadata, and only completed generate_avatar results are eligible. It does not discuss side effects like overwriting or reversibility, but for a save operation with no destructive hint, this is reasonably transparent.

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, no wasted words. The lead sentence states the purpose, the second explains parameter roles, and the third adds usage timing and eligibility. Information is front-loaded and easy to scan.

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 3 params, no output schema, and no nested objects, the description covers the key operational constraints: when to invoke (after generation, user choice), eligibility (only generate_avatar results), and how results map to slots. It does not state what the response returns (e.g., saved avatar ID), but given lack of output schema, this is a minor gap.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the roles of generation_result_id as 'identity-anchor result' and additional_result_ids as 'view results' that fill slots in avatar_creator.view metadata. This goes beyond the schema's per-parameter descriptions, which individually explain what the IDs are but not their functional relationship in the saved avatar.

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

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

The description states a specific verb ('Save') with a specific resource ('completed generate_avatar image results') and outcome ('as one reusable avatar/model'). It clearly distinguishes from sibling tools by restricting to generate_avatar results, unlike upload_avatar_from_chat_file or create_avatar_from_references.

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

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

Provides explicit timing context: 'Use only after generation finishes and the user chooses the candidates.' Also includes an exclusion: 'Normal text-to-image results are not eligible.' While it doesn't name alternative tools, the guidance clearly indicates when to use and when not to use, differentiating from related file-upload or reference-based avatar creation tools.

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

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

Annotations declare readOnlyHint=false but the description adds no explicit mutation/disclosure context. However, the description does clarify important operational behavior: it explains the ordering requirement between files[] and image_file_N, states 'no base64, no local paths' (a notable constraint), and clarifies use of host-supplied file objects versus bare IDs. For a write tool with these annotation hints, this adds 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 compact (three sentences) with no fluff. It front-loads the core purpose, then adds the critical ordering instruction and the domain exclusions. Every sentence earns its place, though the inclusion of maxItems=10 and the host-file-object guidance is partially redundant with 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?

With 14 parameters, no output schema, and no optional param enums, this is a complex tool. The description covers the core use case (reference images), the ordering requirement, the image_url vs. image_file distinction, and the exclusion boundaries. It could be slightly more complete on what the return value signifies (does a successful batch save return saved file IDs?) but remains adequately complete for invocation.

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% and each parameter (files[], image_file_N, image_url, mime_type, file_name) has a solid schema description. The tool description adds key cross-parameter semantics: the ordering relationship between files[] and the top-level image_file_N parameters, plus the 'choose one of image_url or image_file' mechanism. This goes beyond the individual schema fields and compensates well.

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 states the specific action ('batch save reference images from chat attachments into the Files library') with a clear verb and target resource. It distinguishes from other upload tools by explicitly excluding garments/avatars ('not garments or avatars'), though it doesn't name the specific sibling alternative tools (upload_garment_from_chat_file, upload_avatar_from_chat_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?

The description clearly states when to use it ('mood boards, backgrounds, and other reference images') and defines exclusions ('not garments or avatars'). It lacks explicit naming of alternative tools or when-not instructions, but the domain boundary is well established through which sibling tools exist.

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 set destructiveHint=true; the description adds that updates are complete replacements, that the action persists but does not generate images, and that batch_workflow templates are read-only history. No contradiction with annotations; it supplements them usefully, though it doesn't detail revision-mismatch 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?

Four sentences, front-loaded with the core action, each earning its place: create/replace mechanics, persistence behavior, single-generation scope, and alternative routing. 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?

For a complex 7-parameter tool with a rich schema and no output schema, the description is complete: it explains operation semantics, replacement safety, side effects, what does not happen (image generation), and when to use a different workflow. Nothing essential is missing.

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