Uwear

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

Annotations only say non-readonly, non-destructive, non-idempotent; the description adds the substantive behavior: each photo is saved to the library, a repeat is reused, it is added to the board, and the return includes pile and asset id for propose_brief/update_brief. It also discloses the unsure-two-candidates flow and that Uwear auto-sorts unlabeled photos, none of which is derivable from 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 activation condition is correctly front-loaded, but the body is a set of long run-on sentences dense with internal jargon ('Uwear sorts the rest', 'returns its pile'), which slows parsing. Nearly every clause carries information, but the packaging is heavier than needed for a 15-parameter tool.

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 15-parameter nested-schema mutation with no output schema, the description covers trigger, refusal case, kind/side/back_of semantics, and what is returned (pile and asset id). The main omission is the upload_handles / upload_command escape hatch for oversized files, which is only discoverable 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 coverage is 100%, so baseline is 3; the description still earns a bump by giving the ordering rule (attachment order into image_file_1, image_file_2, ...), the meaning of avatar ('a person to use as a Model'), the sides default, and the matching rule for back_of. It never mentions upload_handles or the upload_command retry, leaving that two-step path to 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?

Opens with a concrete trigger and verb+resource: attaching images in the chat and getting them onto the Shoot Board in Uwear, with the accepted photo categories spelled out. It does not name the near-sibling upload paths (save_reference_file_from_chat_file, upload_avatar_from_chat_file, upload_garment_from_public_url), so the agent must infer the boundary from 'Chat attachments only: a web address is refused'.

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?

States the activation condition ('when the user attaches images in this chat and wants them in Uwear'), the exclusion ('Chat attachments only: a web address is refused (ask the user to attach that photo)'), and the re-invocation path when a photo returns unsure – 'ask the user and call again with the same files, kinds, sides and back_of'. When-to-use, when-not, and the follow-up loop are all explicit.

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

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

Annotations already declare destructive, non-read-only and idempotent, but the description adds context the annotations cannot: that no approval prompt may be shown to the client, that stale expected_brief_revision or expected_total_credits causes a no-op with the current brief returned, and that the idempotency key prevents double charging. It does not say what a successful run yields or how to follow progress.

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

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

Front-loaded with what it does and what it costs, then the gating rule, then the validation and idempotency guarantees. Dense but every clause carries operational meaning; the approval-prompt sentence is long but earns its length given the risk of unauthorized spend.

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

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

For a destructive, credit-spending call with six required parameters, the description covers the preconditions, the stale-data failure mode, and the retry guarantee. The remaining gap is the post-call path — no output schema exists, and it never says what comes back or that get_generation_status / mcp_brief_runs should be used to follow the run.

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 83%, so the baseline is 3; the description raises it by explaining the guard semantics of expected_brief_revision and expected_total_credits (mismatch means nothing runs) and by tying idempotency_key to the no-double-charge guarantee. brief_id and board_id meaning is left to the schema.

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

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

States a specific verb and resource — executes the reviewed photoshoot flow with its declared image and video steps — and names the material consequence (spends credits at the quote). This clearly separates it from propose_brief, get_brief, update_brief and the read-only siblings.

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

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

Explicitly defines the precondition: call only when the user agreed in chat, with a concrete test for what counts as agreement (asking to generate/run) and what does not (a request to change the brief). It also names the fallback when the condition is unmet — give the quote and wait for a yes.

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 this is a write operation (readOnlyHint=false) and not destructive. The description adds valuable context: the backend automatically analyzes the image if no description is supplied, and the tool returns a location_id for later use. This goes beyond the annotations by disclosing the auto-analysis behavior and the reusable nature of the created reference.

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 action, then adds the conditional behavior, then a usage hint. Every sentence earns its place, and the structure is clean and scannable.

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

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

Given the 6 parameters, 2 required, and nested objects, the description covers the key behavioral aspects: what it creates, the auto-analysis fallback, and the returned ID. It does not explain error handling or permissions, but the schema and annotations already cover the parameter details and safety profile. For a create tool, this is reasonably complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, so each parameter is documented in the schema. The description adds minimal extra parameter-specific meaning: it clarifies the behavior of the 'description' parameter (if omitted, backend analyzes the image). This is a useful nuance but does not substantially compensate for the schema already covering all parameters. 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 ('Create'), a clear resource ('reusable location/scene reference'), and the source ('from an image URL'). It clearly distinguishes from sibling tools like create_tag or create_art_direction by focusing on location references. The downstream usage hint ('Use the returned location_id in propose_brief/update_brief') further clarifies its purpose.

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

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

The description implies when to use the tool (to create a location reference for briefs) and gives a downstream usage hint. However, it does not explicitly state when not to use it or name alternatives like update_brief or get_location. Still, the purpose is clear enough that an agent can infer appropriate usage without explicit exclusions.

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

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

Annotations already 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 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the flow is data rather than executable instructions, and flow is null when unsupported workflow nodes are present.

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 short and front-loads the core action. The final sentence 'Changes nothing' is slightly redundant with the annotations, but the rest of the text earns its place by clarifying return and contract semantics.

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 tool with full schema coverage and no output schema, the description provides enough context: what is returned, the null-flow edge case, and the data-not-instructions caveat. It could more fully describe the return shape or prerequisites, but the essential calling information 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 both parameters are already well documented in the schema. The description does not add extra parameter-level 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 uses a specific verb and resource ('Read a saved reusable Automation') and names the exact data returned: photoshoot flow, version, and definition hash. It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools like list_automations or update_automation by name.

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 'before editing it' gives a clear use context that ties this read to a subsequent update. It does not explicitly state when not to use it or name a specific alternative sibling, so it falls short of full when/when-not guidance.

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

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

Annotations already specify non-destructive, idempotent, and closed-world behavior. The description adds useful context by noting that it shows the brief on the board and spends no credits, and it names the returned fields. It does not explain permissions or any other side effects, but with annotations present 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?

The description is two short sentences, front-loads the usage condition, and packs the returned fields and side-effect constraints into minimal text. 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?

With no output schema, the description usefully lists the main returned fields and notes the zero-credit behavior. The required board_id is covered by the input schema, while brief_id is at least named in the description. It is complete enough for a simple getter, though not exhaustive about output shape or error cases.

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

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

Schema coverage is 50%: board_id is described in the schema, while brief_id has no schema description. The description compensates partially by saying the brief is retrieved by brief_id, but it does not discuss board_id or add further parameter guidance. This is adequate but incomplete.

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: get a Shoot Board brief by brief_id. It also lists what is returned (looks, automations, credit quote, status, revision), so the tool's purpose is clear. It does not explicitly distinguish itself from siblings such as list_briefs or read_shoot_board, which keeps it at 4.

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 opening 'Use this when you need...' gives a clear usage context. However, it does not state when not to use it or name alternatives such as list_briefs or read_shoot_board, so it falls short of full routing 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 readOnly, idempotent, non-destructive, closed-world, so 'Changes nothing' is redundant. What the description does add is beyond the annotations: it discloses that responses carry image previews intended to be displayed verbatim and that 'url' points to the original asset. That render-contract is exactly the kind of context annotations can't convey, though it says nothing about pagination or result volume.

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

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

Front-loaded with the intent ('Use this to show results in chat'), then the disambiguation modes, then the rendering rule. It packs a lot into a couple of dense clauses, though the parenthetical '(from mcp_brief_runs)' is slightly opaque to an agent that doesn't know that tool.

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 19-parameter, zero-required, no-output-schema list tool, the definition covers the key decision points: which identifier selects which mode and how to render what comes back. Return shape is only partially described (previews + url), and pagination defaults/limits are left to the schema, but nothing essential for correct invocation 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% across 19 parameters, so the schema already carries the semantics; the description only highlights three of them by name. It adds the relationship 'generation_result_id is the exact integer ID required by QA/edit/upscale/video tools', which is useful, but the many filter dimensions are left entirely to the schema. Baseline 3 with schema doing the heavy lifting.

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

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

States a specific verb and resource ('show results in chat') and enumerates three distinct lookup modes keyed on generation_result_id, generation_id, or query/filters/dates. It's clear what the tool retrieves, though it never names the sibling it differs from (e.g. mcp_read_generation_result or mcp_review_generation_results), so an agent must infer the split.

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 a/b/c mode breakdown is genuine routing guidance: one result by generation_result_id, all results of a job by generation_id, past results by query/filters/dates. It also gives a rendering directive (use previews as-is, never Markdown-embed result URLs, url is the original). No explicit exclusions versus sibling reader tools, but the 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/idempotent/non-destructive, so 'Changes nothing' is mostly a restatement; however, the description adds genuinely new behavioral facts the annotations cannot carry — that a failed job yields a sanitized 'safe error_message' and that credits are reported per job. That is useful context for interpreting the response.

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

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

Two sentences, zero filler: the identity/purpose leads, the sibling routing follows, and the safety note closes. Every clause carries information an agent would otherwise have to infer.

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 takes on responsibility for signaling what comes back and does so at a high level (status, credits, error_message), while the schema fills in the rest. Minor gap: it says nothing about failure/pending states or how long a job may take, which matters for a polling-style status check.

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 generation_id property description is unusually rich (returned fields, model_slug mapping, include_snapshot cost warning). The description only echoes 'by generation_id', adding no semantics beyond the schema, which is the correct baseline-3 outcome when the schema does the heavy lifting.

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

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

States a specific verb and resource ('check one generation job by generation_id') and enumerates what is returned: status, credits, and a safe error_message on failure. It also names the sibling it is not (mcp_brief_runs), so the agent can separate it from the brief-level run listing without opening a schema.

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?

Clearly frames the use case as a single job by ID and routes the agent to mcp_brief_runs when it actually wants a brief's runs. It does not address the other plausibly overlapping siblings (get_generation_results, mcp_read_generation, mcp_read_generation_result), so the disambiguation is helpful but incomplete.

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?

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, idempotentHint, non-destructive and closed-world, so 'Changes nothing' is largely redundant. The description does add behavior not in annotations: the ordering guarantee (most recently used first) and the concrete paging model (10 per page, up to 25, continue with next_cursor), which are real operational facts.

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

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

Two tight sentences with zero filler; the core purpose is front-loaded, and paging plus the read-only note are packed into the same compact statement.

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

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

With no output schema, the description carries the burden of describing returns; it covers count, ordering and row granularity but not which fields each automation row contains. For a low-risk read-only lister with full schema coverage on inputs, this is nearly 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 description merely restates what the schema documents (limit up to 25, cursor as next_cursor from the previous page). It adds no format or edge-case meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource (lists the user's Automations) plus scope, result shape ('one row each'), and ordering ('most recently used first'). No sibling tool lists automations, so there is no ambiguity to disambiguate, and the agent can tell exactly what comes back.

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?

Usage is only implied: the board_id requirement (from Open Shoot Board or context) and the paging hints suggest enumerating automations on a board and browsing when there are more than 10. There is no explicit statement of when to prefer this over other listing tools or any exclusion, so an agent must infer the trigger.

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=false, so the bar is lower. The description adds genuinely new behavioral context: image URLs are opt-in via include_image_url, and search is hybrid across names, metadata, and visual attributes. It does not describe return shape or pagination behavior, but that is a modest gap given the 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?

Three tight sentences, front-loaded with the core action and disambiguation before the capability notes. No filler or restated title text; every clause carries information.

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

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

For a zero-required-parameter list tool with 100% schema coverage and safety annotations, the description covers identity, routing, search modes, and the key opt-in flag. It does not mention result volume/pagination behavior, a minor omission since 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 nine parameters including defaults and constraints. The description reinforces query and include_image_url semantics but adds no syntax or format detail beyond what the schema already states, so baseline 3 applies.

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

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

States a specific verb (List) and resource (the user's Models/avatars), and immediately disambiguates the ambiguous term 'Model' from AI models by naming the sibling mcp_list_model_catalog. An agent can route correctly without opening either schema.

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 names the alternative (mcp_list_model_catalog) and the condition that selects it ('for those [AI models]'), plus states the two search modes (structured filters vs. hybrid query) and when to set include_image_url=true. Both the when-to-use and the sibling alternative are covered.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with 'Changes nothing'. It adds genuinely useful behavior beyond that: newest-first ordering, default page size, the next_before cursor for paging older, and the exact compact row fields returned. Not a 5 only because it doesn't note edge cases like what happens when the board has no briefs.

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 use case and resource are front-loaded in the first clause, and every sentence carries information. The parenthetical parameter list is dense and slightly repetitive with the schema, keeping it just below top marks.

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

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

With no output schema, the description compensates by enumerating the returned row fields (brief_id, title, status, ran_at, etc.) and the paging model. Combined with the annotations, an agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 100%, so the schema already documents limit, before, status, board_id, and automation_workflow_id, including the enum meanings and cursor semantics. The description restates these inline but adds no format or usage detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('find a past shoot… the account's briefs, newest first') and frames the user phrasings that trigger it. It also distinguishes itself from get_brief by pointing there for full values, so an agent can route correctly without opening either schema.

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

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

Gives explicit when-to-use triggers ('run the same as last week', 'what ran') and names the follow-up alternative get_brief for details. The status/automation_workflow_id notes further imply when to narrow versus list broadly.

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

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

Annotations only declare the generic safety profile (readOnly, idempotent, non-destructive), so the description carries the real behavioral load. It discloses the OR semantics between body_zone and category, the scoping rule that uncategorized_count only reports when a category/body_zone filter is active with include_uncategorized=false, and the recovery workflow. Since there is no output schema, surfacing uncategorized_count behavior here is genuinely necessary.

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 purpose, then filter semantics, then the follow-up rule. No filler or repetition of schema text. It is somewhat dense for a single paragraph, but every sentence carries a distinct operational fact.

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 13-parameter, zero-required read tool with no output schema, the description covers the non-obvious interactions (category/body_zone OR, uncategorized handling) that an agent would otherwise get wrong. Pagination, sorting and ID filters are adequately covered by the schema. The main omission is what the response shape looks like beyond uncategorized_count, though that is defensible without 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%, so the baseline is 3, but the description adds meaning the schema does not: body_zone 'expands to categories' (expanding rather than exact-matching), the OR relationship with category, and the conditional semantics of include_uncategorized and uncategorized_count. That is real added value over the per-field schema text.

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 ('List user's garments') and immediately distinguishes two modes: structured filters versus hybrid name/SKU/metadata/image-attribute search. It does not, however, name the closest sibling (e.g. search_uwear_library or list_outfits) to route the agent between them, so the differentiation is functional rather than sibling-aware.

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

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

Gives concrete conditional guidance: body_zone ORs with category when both are supplied, and it prescribes an explicit follow-up ('If matches are short and uncategorized_count > 0, call again with include_uncategorized=true'). That is unusually actionable for a list tool. It stops short of stating when to prefer this tool over the sibling list/search tools.

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

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

Annotations already mark 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 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 declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds value by clarifying that templates persist canonical commands but do not execute generations (a key misconception an agent could have) and that owner-only entries are hidden unless requested. Return shape and pagination behavior are not described.

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, mostly dense and front-loaded, but the middle fragment 'Keeps identify which values apply' is broken and wastes space without conveying anything actionable. Otherwise there is little 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 9-parameter, zero-required listing tool with no output schema, the description covers filtering, sorting defaults conceptually, and the Demo/get_template workflow. It never sketches what a returned template looks like, so an agent must infer the response shape from the schema alone.

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 67%, and the description compensates by naming the filter axes — kind, scope, command use case, creator, public t-xxxx share code — and usage sorting, mapping them to use_case, catalog_scope, created_by_profile_id, share_code and sort. It adds interpretive meaning (e.g. 'command use case') beyond the raw enum fields, though pagination controls go unmentioned.

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?

Opens with a concrete verb+resource ('List canonical company templates') and enumerates the filter dimensions plus sorting, which separates it from sibling list tools like list_briefs or list_art_directions. The fragment 'Keeps identify which values apply' is garbled and slightly muddies an otherwise precise statement of purpose.

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

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

Gives real routing guidance: system templates named 'Demo — …' are worked examples, and the agent should read one via `get_template` before authoring a first brief or workflow. It lacks explicit when-not-to-use and doesn't contrast with other list tools, 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 readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The word 'Append' is consistent with that additive profile but adds no new behavioral information such as the revision-conflict safety mechanism, what happens on stale revisions, or whether duplicate items are merged.

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 short sentence with zero waste, front-loading the verb and resource. It is efficient, though its terseness is the source of the coverage gaps noted elsewhere rather than a structural flaw.

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 multi-parameter write tool with nested context_items, intake states, enum-constrained item types, and a revision-conflict protocol, one sentence is not enough. The description never surfaces the concurrency guard (expected_revision) or the item taxonomy, leaving the agent to reconstruct intent entirely 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 the schema already documents board_id, expected_revision, board_version, and the context_items shape. The description adds nothing beyond the schema, which is the baseline 3 case when structured fields do the heavy lifting.

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

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

States a specific verb and resource: 'Append items to the Uwear Shoot Board.' An agent can tell this is an additive write to a board. However, it does not distinguish itself from close siblings like modify_shoot_board, show_in_shoot_board, or mcp_replace_context, which an agent must choose between.

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 when-to-use guidance, no prerequisites, and no mention of the obvious alternatives (mcp_replace_context for replacing, mcp_clear_context for clearing, modify_shoot_board for edits). The agent is left to infer from the name alone when appending is the right call.

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

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses exactly what is destroyed and under what condition: from_garment_id leaves the board and is deleted 'only when it is a fresh drop nothing else uses,' while the image_url path leaves the board untouched. It also adds side effects (the draft brief is re-saved) and idempotent behavior ('asking again answers status unchanged'), which is exactly the extra context annotations cannot carry.

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 primary drop-on-garment scenario, and every sentence carries information (modes, deletion rule, brief save, return value). Phrasing is slightly telegraphic ('The photo of from_garment_id', 'the board's draft brief is saved again') which costs some readability but not 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 mutation tool with no output schema, the description covers the return value ('Returns the board (and brief)'), the destructive semantics of the source garment, the brief-save side effect, and repeat-call behavior. Combined with the schema's expected_revision conflict documentation, an agent has what it needs to call this correctly.

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

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

Schema coverage is 100%, so the schema already documents all six parameters and the baseline is 3. The description adds real meaning on top: it explains that image_url and from_garment_id are mutually exclusive modes and that from_garment_id causes the source garment to leave the board, which the schema alone does not convey.

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 concrete effect: the photo of from_garment_id becomes the back/side/detail view of garment_id, with a second mode using image_url for the brief's missing-photo slot. An agent can tell what the tool accomplishes, though the framing as a UI gesture ('a Clothing card dropped on another') is less direct than a verb+resource statement, and no sibling is named.

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

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

It clearly lays out two usage modes and the condition selecting each: use from_garment_id when dropping one garment card onto another, use image_url when filling the brief's missing-photo slot. It does not name alternatives such as add_chat_photos_to_board or mcp_upload_intake_photo for routing purposes, so it stops short of explicit when-not guidance.

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

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

Annotations already declare a safe, idempotent, closed read, so the bar is lower. The description adds genuine behavioral value beyond them: sort order ('newest first'), the exact inclusion rule (all account briefs plus this board's draft), and the shape of each item (status, looks, automations, credits, covers).

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 dense sentence that front-loads the resource and ordering before the scope enumeration. No filler, though the trailing field list makes it slightly heavy.

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

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

With no output schema the description usefully enumerates returned fields, and the tool is a simple 2-param read, so safety and scope are covered. However, the page parameter and pagination behavior are unexplained, leaving an agent unable to call the tool correctly for multi-page results.

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

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

Schema coverage is only 50%: board_id is documented in the schema but the page parameter has no description anywhere. The description never mentions pagination or what board_id scopes, so it does not compensate for the coverage gap.

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

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

States a specific verb+resource (list the account's Shoot Board briefs) and even defines the exact scope returned: every brief that ran plus this board's draft. It does not name or differentiate against siblings like get_brief or mcp_brief_runs, so it stops short of a 5.

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?

There is no explicit when-to-use guidance and no alternative is named. The scope sentence ('every brief that ran ... and this board's draft') implies this is the broad listing versus get_brief's single fetch, but the agent must infer that rather than being told.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the 'Changes nothing' clause is redundant, but the description adds genuinely new behavior: this is an asynchronous job that must be re-polled until done is true, and the agent should narrate progress while the board shows it. That polling/settling semantics is not derivable from the annotations and is the key thing an agent needs.

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

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

Front-loaded with the usage trigger, then return shape, then polling loop, then follow-up - a sensible order. Somewhat run-on with stacked parentheticals, but every clause carries information; nothing is padding.

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, and the description does the necessary work by enumerating what comes back (status, credits, results, failures, done). With annotations covering safety, the main gap is the undocumented workflow_run_ids parameter and the exactly-one constraint, which leaves it slightly short of fully self-contained.

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

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

Schema coverage is only 33% - only board_id carries a schema description, and the object-level 'exactly one' note is the only guidance for brief_id vs workflow_run_ids. The description references brief_id in passing but says nothing about workflow_run_ids (up to 50 UUIDs) or the mutually exclusive selection, so it fails to compensate for the coverage gap.

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

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

States clearly what the tool returns: each look's run for a brief_id with status, credits, results (generation_result_id, kind, url) and per-step errors. The verb is implicit ('follow' / 'how a shoot is going') rather than a crisp verb+resource, but an agent can determine what the call produces. It distinguishes itself from confirm_brief (upstream) and get_generation_results (downstream), though not from the sibling get_generation_status.

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

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

Explicit trigger conditions: 'after confirm_brief or when the user asks how a shoot is going', plus a polling instruction ('Read it again until done is true') and a downstream routing hint ('show the results with get_generation_results'). No exclusion statement, and it never contrasts with get_generation_status, so a sibling ambiguity remains.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is fully covered by structured data. The description adds no extra behavioral context such as irreversibility of the wipe, the revision-conflict guard, or what happens to dependent items; it essentially restates the purpose.

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 tight sentence with the primary action front-loaded and the variant clause second. No filler, though the extreme brevity leaves room for a clause that would earn 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 destructive, revision-guarded write with no output schema, the annotations and 100% schema coverage carry most of the load, so the description is minimally sufficient. It nonetheless omits confirmation of irreversibility and the revision-conflict recovery path, which an agent invoking a destructive clear would benefit from.

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

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

Schema description coverage is 100%, so all four parameters (including the type enum and expected_revision) are already documented in the schema. The description's 'only one context type' merely echoes the type parameter's own description, adding no syntax or format detail beyond it.

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

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

The description names a specific verb (clear) and resource (Shoot Board items), plus a scope variant (a single context type). It is distinguishable from siblings like mcp_add_context and mcp_replace_context by verb, though it doesn't name those alternatives directly.

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 'or only one context type' implies the two usage modes (clear everything when no type is given, clear selectively when it is), but no explicit when-to-use or when-not-to-use guidance is provided relative to replace_context or modify_shoot_board. Usage is inferable from the schema rather than stated.

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

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

Annotations cover the safety profile (non-read-only, non-destructive, idempotent), and the description adds real behavioral context beyond them: dedup by already-saved state, optimistic concurrency via expected_revision, and the atomic guarantee that a stale board is refused before anything is saved with a revision_conflict payload. That is exactly the write-failure semantics an agent needs before invoking.

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 front-loaded sentence that leads with the action, then the dedup rule, then the concurrency clause. The semicolon-chained clauses are dense but each carries information; nothing is padding.

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

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

There is no output schema, and the description still discloses the failure shape (revision_conflict with the current board) and the atomicity guarantee, which is the main uncertainty for a batch write against a versioned board. Required inputs and their roles are otherwise fully documented in 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%, including detailed per-field docs for items, sha256, views and side, so the schema carries the load. The description only restates expected_revision's conflict behavior (already in the schema) and adds no syntax or format detail of its own; baseline 3 applies.

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

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

States a specific verb and resource: it saves sorted Shoot Board photos into the library as one of four asset kinds, then attaches them to the board. The batch/dedup/revision-check framing implicitly separates it from single-asset siblings like mcp_upload_intake_photo and upload_garment_from_public_url, though it never names an alternative explicitly.

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 places the tool in a clear workflow (photos are already sorted and screenshotted/uploaded; this commits them), and notes that already-saved photos are skipped rather than erroring. It gives no explicit exclusion such as 'use upload_garment_from_public_url for a single non-board garment', so guidance is clear but not complete.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds genuine context beyond that: it also destroys stored images, and it requires prior in-chat user confirmation. It does not disclose irreversibility beyond what destructiveHint implies, nor any batch/limit behavior, keeping it below 5.

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

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

Two sentences, action front-loaded and the precondition second — no filler. The 'as the platform's Delete' phrase is slightly redundant and costs a small amount of clarity.

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

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

For a destructive delete with no output schema and no param docs, the description covers the essentials: what gets removed, that it is irreversible, and the confirmation gate. It omits how to source valid IDs and the 100-item batch ceiling, which are the remaining operational 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 0%, so the schema supplies structure only (array of positive ints, 1-100 items) with no semantics. The description alludes to 'which results to delete' but never explains the parameter's format, valid range, or where IDs are obtained; it does not compensate for the coverage gap.

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

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

States a specific verb (Delete) and resource (the user's results and their stored images), and clarifies it maps to the platform's own Delete. An agent can distinguish it from read-side siblings like mcp_read_generation_result and sibling mutations like set_generation_result_favorite. The 'as the platform's Delete' clause is slightly awkward but does not obscure the 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?

Gives an explicit precondition for invocation: 'call it only after the user confirmed in chat which results to delete.' This is exactly the gating guidance a destructive tool needs. It stops short of naming an alternative or where the IDs originate, so not a full 5.

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world, so the bar is lower; the description still adds real value by disclosing that the edit is saved as a NEW brief linked to the board (versioning, not in-place mutation) and that the response includes board, brief, quote and credit delta. It does not mention the expected_brief_revision concurrency guard, though the schema does.

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, no filler: the first names the action and the operation families, the second covers the save semantics, return payload and dry_run. Purpose is front-loaded ahead of behavioral 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 complex multi-op mutation tool with no output schema, the description does state what is returned (board, brief, quote, credit delta) and that a new brief is saved. Remaining gaps are sibling routing guidance and the concurrency/idempotency contract, the latter of which the schema covers via expected_brief_revision.

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 80%, so the schema already documents board_id, brief_id, expected_brief_revision and dry_run. The description's op enumeration ('add, remove or change looks, or run looks through another automation') covers only a subset of the ten available ops (direction, models, output, refresh, restore, discard are unmentioned), so it neither adds nor fully compensates.

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 ('Edit the Shoot Board's brief') and enumerates the main operation families (add/remove/change looks, run looks through an automation). It does not distinguish this from close siblings like update_brief, propose_brief, or confirm_brief, so an agent cannot route purely from the description.

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?

'By hand' signals a manual-edit path and 'run looks through another automation' hints at the recipe workflow, plus 'dry_run only quotes' gives a preview usage pattern. But there is no explicit statement of when to choose this over update_brief or propose_brief, and no prerequisites or exclusions are given.

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?

Adds two pieces of context beyond the annotations: that the call 'spends credits' and that it 'returns the generation_id to poll with get_generation_status.' The credit-cost warning and the follow-up polling workflow are genuinely useful behavioral facts the annotations (destructive, non-idempotent) don't convey. Could say more about irreversibility, but it is solid.

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 tight sentences, each earning its place: purpose, cost/precondition, and return handling. No redundancy or filler, and the most important constraint 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?

With no output schema, the description correctly carries the return-value burden by naming generation_id and the polling tool. Combined with the credit and confirmation caveats, an agent has what it needs to call this correctly, though edge cases (failure handling, credit cost magnitude) remain unstated.

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 seven clip sub-fields and output settings are already documented structurally. The description only reinforces the clips/order concept without adding syntax, format, or constraint detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (Export) and resource (montage clips stitched into one video), which is clear and distinguishable from propose_montage/update_montage_proposal. It stops short of explicitly naming an alternative tool for the agent to compare against, but the action 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?

Gives an explicit precondition: 'call it only after the user confirmed the clips and their order in chat.' This is strong when-to-use guidance. It does not enumerate alternatives, but the confirmation gate is the operative condition and is clearly stated.

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

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

Annotations declare non-read-only, non-destructive, non-idempotent. The description is consistent, adding that the output is a NEW image result (so nothing existing is destroyed) and the endpoint. It does not explain what happens on repeat calls (idempotentHint=false implies duplicates) or auth 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?

One tight sentence plus a UI anchor phrase; the action and output are front-loaded with no filler. Slightly terse rather than padded.

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

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

For a mutation with no output schema that produces a brand-new artifact, the description never indicates what is returned (e.g., the new image result id) or how the new frame relates to the source result. Combined with the undocumented required parameter, an agent lacks enough to use it confidently.

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

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

Schema coverage is only 50% and the description names no parameters at all. It says 'a still frame' without clarifying which frame, so the caller learns nothing about timestamp_seconds (last frame by default) or the required generation_result_id beyond what the schema shows.

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: 'Save a still frame of a video result as a new image result', plus the underlying route. It is clearly distinguishable from siblings like mcp_save_retouch or mcp_generate_clip, though it doesn't explicitly name a 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?

The phrase 'The result viewer's Save frame' anchors the tool to a known UI action, implying when it applies. However, it gives no conditions for choosing it over alternatives and no exclusions or prerequisites, leaving usage largely inferred.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds value the annotations cannot: it spends credits and requires prior user consent in chat, and it returns a generation_id. These are important operational facts (cost and confirmation) beyond the safety profile.

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

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

Three tightly written sentences, each earning its place: what it does, the cost/consent constraint, and the follow-up call. The most critical constraint (spends credits) is front-loaded within the first two sentences.

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

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

For a 9-parameter mutation tool with a fully documented schema and no output schema, the description covers the essentials an agent needs: the action, cost, consent gate, and the returned generation_id for polling. It is near-complete, lacking only explicit guidance on the mutually exclusive source parameters.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no per-parameter meaning (defaults, mutual exclusivity of the three source parameters, etc.) beyond what the schema already documents in detail.

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

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

The description states a specific verb and resource: 'Queue an image-to-video generation for one montage clip.' The 'one montage clip' scoping and the image-to-video modality make the operation concrete. It does not explicitly differentiate from siblings like propose_montage or queue_generation_result_qa, which keeps it from a 5.

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 a clear precondition ('call it only after the user agreed in chat') and routes the agent onward to get_generation_status for polling. This is actionable when-to-use guidance, though it doesn't state explicit when-not conditions or name a competing generation tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no note on required board state, no note on what 'context' means, no indication of whether an open board session is needed.

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?

It is a single short sentence with no wasted words, which is structurally clean. But the brevity here reflects under-specification rather than efficient front-loading, so it does not rise above adequate.

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

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

There is no output schema, so the description should carry more weight regarding what a 'read' returns, yet it says nothing about return shape or how the result differs from read_shoot_board. For a tool whose name/title disagree and that has a near-identical sibling, this is incomplete.

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 (board_id, board_version with its enum) are documented in the schema itself, so the baseline is 3. The description contributes no additional meaning about the 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 one-liner does state a verb (Read) and a resource (the Uwear Shoot Board), which is minimally specific. However, it gives no way to distinguish this tool from the sibling read_shoot_board, and the tool name mcp_get_context actively misleads toward generic context retrieval. An agent cannot tell from the description why two read-board tools exist.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative read_shoot_board. The only faint signal is that it reads a board, which the name and title already imply.

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, and the description reinforces this with 'Saves nothing' rather than contradicting it. It adds genuinely useful behavior beyond annotations: duplicate detection within the drop and against the library, and the deferred-error/retry contract.

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 dense sentences, front-loaded with the action and categories, with no filler. The critical non-destructive and retry facts are stated compactly.

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 does the work of describing returns (category assignment, unsure-with-two-candidates, duplicate reports) and the deferred error case. It is largely complete, though the result shape/index mapping is left to 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%, covering sha256, image_url, file_name, and board_id in detail, so the schema carries parameter meaning. The description adds only a light hint about drop order/results indexing, which the schema already states.

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

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

States a precise verb ('sort') and resource ('photos dropped on the Shoot Board'), then enumerates the output categories (garment, avatar, location, reference, unsure-with-two-candidates) and the duplicate reporting. The 'Saves nothing' clause immediately separates it from write siblings like mcp_commit_intake.

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?

Clarifies it is a non-committing pass, implies the commit step lives in a sibling, and gives clear retry guidance for the deferred case. It stops short of naming the alternative tool or stating explicit when-not 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful scoping context that results come from two tabs, but says nothing about pagination defaults, result merging, or ordering. 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 front-loaded sentence with no filler or redundancy. Efficient, though it is arguably too terse for a 4-parameter listing tool where extra routing context would earn 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 read-only list tool with full annotation coverage and no output schema, the description is minimally complete. It lacks disambiguation from sibling listers, pagination behavior, and whether results from the two tabs are combined or separate, leaving real gaps for an agent to fill.

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

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

Schema description coverage is 100%, so all four parameters (page, limit, query, tag_ids) are already documented in the schema; baseline is 3. The description adds no parameter-level meaning beyond the schema, and the schema's note that 'query' searches only the References tab is not reconciled with the description's claim of covering both tabs.

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

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

States a specific verb+resource ('List uploaded (reference) files') and scopes it to two concrete surfaces (the workspace files tab and the Shoot Board References tab). This is clear, but it does not distinguish itself from overlapping siblings like mcp_workflow_assets, mcp_intake_files, or search_uwear_library, so an agent cannot fully disambiguate on the description alone.

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 when-to-use, when-not-to-use, or alternative guidance is given. With many sibling listing/search tools (list_tags, mcp_workflow_assets, search_uwear_library), the description offers no signal on when this tool is the right choice over those.

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, which fully characterize this as a safe, repeatable read. The description adds that it reflects 'as GET /models returns them' and that the catalog is 'active' models, which adds minor scoping context but no auth, rate-limit, or freshness detail beyond the annotations.

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

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

A single front-loaded sentence with no filler or repetition. The embedded clauses ('as GET /models returns them', 'for the widget's model pickers') are compact, though slightly qualifier-heavy.

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 (no params, no output schema) and the description covers what is returned, its scope, and the intended consumer. For such a low-complexity, annotation-backed read tool, this is nearly complete; only the return shape and any update cadence are unspecified, which is acceptable.

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

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

There are zero parameters, so the schema needs no compensation and the baseline is 4. The description correctly implies that no filtering or query options exist, matching the empty parameter object.

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 (list) and resource (model catalog), naming returned content: active AI models with capabilities and pricing rules. It is clearly distinguishable from the many list_* siblings by its subject matter, though it doesn't contrast against an obvious direct alternative.

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 'for the widget's model pickers' implies the consumer context, giving some sense of when it matters. However, there is no explicit when-to-use/when-not guidance and no named alternative 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lowered. The description adds real value by disclosing the returned fields (prompt, model, settings, inputs), which matters since there is no output schema; it stops short of describing error behavior for a missing id.

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 front-loaded sentence that names the resource first, then the returned contents, then the use case. The API-path reference is slightly technical filler but overall efficient.

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 with annotations covering safety, the description supplies the return contents and use context. Missing only edge-case behavior (unknown id), which renders it nearly 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?

With one parameter at 0% schema coverage, the description only implicitly maps generation_id via the GET /generation/{id} path and "one generation." A single integer id is largely self-evident, so this is adequate but adds little beyond the schema.

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

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

States a specific verb (read) and resource (one generation with its results) and enumerates the returned content (prompt, model, settings, inputs), with the API mapping GET /generation/{id}. It is clear on its own but does not differentiate from close siblings such as mcp_read_generation_result, get_generation_results, or get_generation_status.

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

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

The phrase "for the result viewer's Info panel" implies a usage context, but there is no explicit when/when-not guidance and no alternative tool is named. An agent must infer when to pick this over the other generation-reading 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 establish read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds value beyond them by enumerating what comes back (tags, review verdict, QA, prompt, model), which is meaningful given no output schema exists. It does not mention error behavior or that the id must come from a prior listing 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?

A single dense sentence, front-loaded with verb and resource and then the returned field list. Nothing is wasted, though the trailing widget-viewer clause is of marginal value to an agent and the sentence is a fragment rather than complete prose.

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 correctly compensates by naming the returned fields, and the endpoint reference anchors the resource identity. It is nearly sufficient for a one-parameter read tool; missing only guidance on sourcing the id and on error cases.

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

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

Schema description coverage is 0% for the single required parameter generation_result_id, so the description carries the burden. The embedded endpoint template /generation-result/{id} implies the value identifies a result, but there is no detail on where to obtain the id or its accepted range beyond the schema's minimum.

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

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

States a specific verb+resource ('One generation result') and even pins the underlying endpoint GET /generation-result/{id}, which cleanly distinguishes it from the plural sibling get_generation_results. It does not explicitly name that sibling or mcp_read_generation, so differentiation is implied rather than stated.

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?

'For the widget's result viewer' gives an implied usage context, but it is framed as a caller's need rather than agent guidance. No when-to-use/when-not guidance and no routing against get_generation_results, mcp_read_generation, or read_generation_result_qa, which all appear in the sibling list.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the safety profile is covered. The description confirms creation of a *new* copy, which is useful, but says nothing about what is duplicated (version, asset bindings), whether the source is left untouched, or permission requirements. Adequate but thin for a duplication operation.

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

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

A single tight sentence with the verb and scope front-loaded and no filler. It is efficient, though its brevity contributes to the gaps in other dimensions rather than being a virtue on its own.

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 four-parameter mutation with 25% schema coverage, no output schema, and no annotations explaining what is created or which optional fields default to what. The description does not fill those gaps, leaving the agent under-informed about how to call it correctly.

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

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

Schema description coverage is only 25% – just board_id is documented – so the description is expected to compensate and does not. It never explains that 'name' sets the new copy's title, that source_version_id picks which version to duplicate, or that source_workflow_id identifies the source recipe. Half the parameters remain semantically opaque.

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 clear verb+resource: copying an automation into a new one scoped to this shoot. However, it uses 'automation' where the tool name and siblings use 'recipe', and it does nothing to distinguish itself from mcp_recipe_list, mcp_recipe_open, mcp_recipe_save_draft, or mcp_recipe_preflight. An agent gets the gist but must infer the relationship to those siblings.

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

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

There is no explicit when-to-use guidance and no named alternative. 'For this shoot' hints at context but never states when an agent should duplicate rather than open, edit, or list a recipe. The agent must guess the triggering condition.

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=false, so safety is covered. The description adds genuinely useful behavioral detail not in the annotations: results are ordered newest first, one row per run, and each row carries timing, outcome, credits and covers. It omits pagination behavior even though a page parameter 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?

A single dense sentence that front-loads the resource and ordering, with no filler. The parenthetical 'its looks' is slightly awkward but does not cost much space.

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

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

With no output schema, the description usefully enumerates the returned fields, which is the right instinct. However, two of three parameters remain undocumented and pagination/result-count behavior is unstated, so it is only adequate for a read tool that requires two identifiers.

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

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

Schema description coverage is only 33%: board_id is documented in the schema, workflow_id and page are not. The description adds nothing about parameter meaning, format, or what page does, so it does not compensate for the coverage gap.

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

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

The description names the resource (an automation's past runs) and the shape of the result (one row per Shoot Board Generate or per Uwear run, with timing, outcome, credits, covers). It is specific enough to distinguish from mcp_recipe_list and mcp_brief_runs, though the phrasing ('its looks') is slightly idiosyncratic.

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?

There is no statement of when to call this versus mcp_brief_runs, mcp_recipe_preflight, or mcp_recipe_open, and no prerequisites beyond what the schema requires. Usage must be inferred from the name and required parameters 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds only a loose scope statement and says nothing about pagination, return shape, or the effect of the include_* flags beyond what the schema already notes.

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?

It is short, but this is under-specification rather than conciseness: a single sentence fragment that omits the core action verb, so it does not front-load a usable statement of what the tool does.

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 paginated, filterable listing tool with six parameters and no output schema, the description is far too thin. An agent cannot tell what is returned, how paging behaves, or how this differs from the other mcp_recipe_* tools.

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?

Six parameters at 67% schema coverage, and the description contributes no meaning for any of them — not the required board_id, the query search, paging, or the include_automations/include_definitions toggles. It neither supplements the documented params nor compensates for the undocumented ones.

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 is a noun fragment — 'The company's shoot automations (and other automations to copy)' — with no verb stating that it lists them. It names the resource but the parenthetical 'and other automations to copy' muddies scope, and it never distinguishes this from siblings like mcp_recipe_copy, mcp_recipe_history, or mcp_recipe_open.

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?

There is no explicit when-to-use or when-not-to-use guidance. The phrase 'to copy' faintly implies this feeds mcp_recipe_copy, but the agent must infer that; no alternative or condition is named.

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 disclose the non-read-only, non-idempotent, non-destructive profile, so the bar is lower. The description adds real behavioral value beyond that: saving an edit spawns a new automation rather than mutating the existing one, and non-brief automations open read-only. It stops short of stating auth/permission requirements or what the builder returns.

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 purpose is front-loaded, which helps, but the remainder is a single dense run-on sentence with nested parentheticals ('its draft, or once Generate published it its live version (saving an edit of it makes a new automation)') that is hard to parse on first read.

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

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

There is no output schema, so return values need not be described, and annotations cover the safety profile. The description covers the key edit-vs-read-only nuance but leaves workflow_id unexplained and the opening/closing UI flow ambiguous, which is a gap for a 4-parameter 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 75%, so the schema documents board_id, read_only, and version_id in detail; only workflow_id is undocumented there. The description's 'another automation opens read-only' and the draft-vs-live explanation give some meaning to workflow_id/version_id selection, but it does not compensate for the untagged workflow_id or add format details. 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: 'Open the brief's automation in the builder,' and goes on to distinguish the draft vs. the published/live version. However, it never names or contrasts a sibling like mcp_recipe_list, mcp_recipe_copy, or mcp_recipe_save_draft, so the agent must infer why it would open rather than list or copy.

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?

Usage is implied: opening a brief's automation puts you in an editable builder ('saving an edit of it makes a new automation'), while 'another automation opens read-only.' There is no explicit when-to-use/when-not guidance or pointer to the alternative tools for listing, copying, or saving drafts.

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=false, so the safety profile is covered. The description adds the useful fact that this both validates AND prices, which is more than a plain read, but says nothing about failure behavior or what a failed validation means.

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 front-loaded sentence with zero wasted words. It is efficient, though arguably too terse for a four-required-parameter tool, which keeps it short of a 5.

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 taking a nested authoring graph and three identifiers, with no output schema, the description should explain what validation reports and how pricing is expressed. Instead it stops after one clause, leaving output shape and error semantics undocumented.

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

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

Schema coverage is only 50%: graph and board_id are documented, but workflow_id and version_id carry only a UUID pattern with no meaning. The description adds no parameter context at all, so it fails to compensate for the coverage gap.

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

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

States two specific verbs (validate, price) against a clear resource (the automation/recipe being edited), so the agent knows it is a preflight check rather than a read or save. However it never names sibling tools like mcp_recipe_save_draft or mcp_workflow_contract, so differentiation must be inferred.

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 'being edited' faintly implies it belongs in the edit flow, but there is no explicit when-to-use, no prerequisite (e.g. a recipe must already be open), and no mention of alternatives. An agent gets no routing 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 destructiveHint=true, idempotentHint=false, and readOnlyHint=false, and the description does not contradict them. However, it adds no behavioral context beyond those hints — nothing about what a save overwrites, hash guarding, or concurrency — so it contributes no value over the structured metadata.

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?

It is a single short sentence with no wasted words, but this length reflects under-specification rather than conciseness. There is nothing front-loaded to help an agent decide or act.

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 10-parameter destructive mutation tool with no output schema, the description omits required inputs, the meaning of optional fields, and the version/hash semantics that govern whether it POSTs or PATCHes. An agent cannot safely invoke this from the description alone.

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?

There are 10 parameters and schema description coverage is only 10%, so the description carries the burden of explaining parameters and instead says nothing about any of them (nodes, edges, failure_policy, expected_definition_hash, result_projection, version_id). None of the ambiguous or untyped fields are clarified, leaving the caller to guess.

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 'Save the automation's draft' essentially restates the name and title (mcp_recipe_save_draft / Save Automation Draft) without adding scope, target, or effect. It does not distinguish itself from close siblings like mcp_recipe_open, mcp_recipe_copy, or mcp_recipe_preflight beyond the generic word 'save'.

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 when-to-use guidance is given: it doesn't say when a draft should be saved versus using recipe_preflight, recipe_open, or recipe_history, nor mention prerequisites such as an open board. The one useful routing hint (new draft vs existing version) lives in the schema, not the description.

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

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

Goes well beyond the annotations: it discloses that the image is re-saved as the new kind and swapped on the board, and that the old asset is deleted only if intake saved it within 24 hours and nothing references it, otherwise it remains in the library. It also explains the idempotent no-op and its 'unchanged' board return, adding real destruction and side-effect context on top of destructiveHint/idempotentHint.

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

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

Front-loaded with the action and its scope, then the side-effect conditions. Two sentences carry a lot of conditional detail, which is dense but every clause earns its place; only slight compression is possible.

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

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

For a destructive, nested-object mutation with no output schema, it covers the important unknowns: what is destroyed and when, that re-issuing is a no-op, and the 'unchanged' return. It stops short of covering permission/authorization needs or failure modes beyond the schema-described revision conflict.

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 four parameters, including the revision-conflict semantics of expected_revision. The description's mention of the three pile names merely restates the enum, so a 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 ('Move a Shoot Board photo') and bounds it to three enumerated piles (Clothing, Models, Locations), which separates it from the generic modify_shoot_board sibling. An agent can tell exactly what this does without opening the schema.

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 conditional behavior ('a move that already happened changes nothing') but never says when to prefer this over modify_shoot_board or show_in_shoot_board, nor what preconditions (e.g. an open board) are required. Usage is implied rather than stated.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is partly covered. However, the description omits important behavior the schema implies: that this is a full-list replacement, that context_state takes precedence over context_items, and that a stale expected_revision returns a revision_conflict error rather than overwriting. It adds essentially nothing beyond the annotations.

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

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

The single sentence is short but this is under-specification rather than conciseness. For a destructive, nested, five-parameter tool, one sentence cannot carry the necessary information, and there is nothing to front-load.

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 a destructive full-replace tool with nested item objects, a context_state precedence rule, and a revision-conflict mechanism, the description leaves the agent without any of that. Annotations cover only the generic safety profile and there is no output schema, so the description should have done far more.

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

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

Schema description coverage is 100%, so the schema fully documents board_id, board_version, context_items, context_state, and expected_revision (including the revision_conflict behavior). The description adds no parameter meaning of its own, so the 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 "Replace the Uwear Shoot Board items" is essentially a restatement of the title "Replace Shoot Board" plus the word "items". It gives a verb and resource but offers no scope or differentiation from close siblings like modify_shoot_board, mcp_add_context, and mcp_clear_context, which an agent would need to tell apart.

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 when-to-use, when-not-to-use, or alternative is named, despite obvious candidates in the sibling list (modify_shoot_board for partial edits, mcp_add_context for appends, mcp_clear_context for wiping). The only implied guidance comes from the verb "replace".

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 destructiveHint=true declared, the description does valuable disambiguation work by clarifying that 'deletes nothing' — i.e. the destructive aspect is overwriting a prior verdict, not data loss — and it adds the non-obvious 'spends no credits' fact. It stops short of covering ownership/permission requirements or per-item behavior for a batch of up to 50 ids.

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?

Compact and front-loaded: the operation is stated first, then the value space, then the two guardrails. Only 'The result viewer's review rail' is filler, though it does locate the surface in the UI, so almost every clause earns its place.

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

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

For a mutation tool with no output schema, the description plus annotations cover what an agent needs: what is set, what it replaces, that nothing is deleted, and that no credits are spent. Ownership is scoped ('their own results'), and remaining omissions (batch size, note semantics) are documented in the schema itself.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains the semantically tricky 'decision' enum well, including that null clears the verdict, but says nothing about the 'note' parameter or why 'generation_result_ids' is an array (batch of 1-50), leaving two of three parameters undocumented.

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

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

States a specific verb and resource ('Sets the user's verdict on their own results') plus the exact value space (approved/rejected/null), so an agent knows precisely what the tool mutates. The phrase 'deletes nothing and spends no credits' implicitly separates it from the sibling mcp_delete_generation_results and from any generation-spending tool.

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

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

Usage is implied rather than stated: an agent can infer this is the tool for triaging results, and the 'deletes nothing' clause hints at the delete sibling's domain. However, no alternative is named explicitly, and there is no guidance on when to prefer mcp_set_generation_result_tags or set_generation_result_favorite instead of setting a verdict.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds the useful structural fact that a new child result is created rather than mutating the parent, but it does not warn that repeated calls create duplicate children (consistent with idempotentHint=false) or mention any permission/error behavior.

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

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

Two short sentences, zero filler, with the core action and the parent linkage front-loaded. Every clause earns its place.

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

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

For a five-parameter save tool with no output schema, the description covers the write semantics but says nothing about what is returned (e.g., the new result ID) or failure modes such as an invalid parent_generation_result_id. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so all five parameters are already documented. The description reinforces the relationship between image_base64 and parent_generation_result_id (child-of-parent), but adds no syntax, format, or constraint details beyond the schema; baseline 3 applies.

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

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

States a specific verb (save) and resource (edited/retouched image) and clarifies the result is stored as a new child of parent_generation_result_id. It is distinguishable from generation and read siblings, though it never names a contrasting sibling tool explicitly.

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?

Usage is implied: call this when you have a retouched image to persist under an existing generation result. The clause 'Changes no existing result' hints at the non-destructive scope, but there is no explicit when-to-use/when-not guidance or named 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 declare destructiveHint=true and idempotentHint=true, but the description adds genuinely new behavior: full replacement semantics ('empty removes all') and a real side effect not in annotations — 'A tag that starts one of the user's automations starts it'. That automation trigger is the kind of consequence an agent must know before invoking.

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

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

Three short sentences with the core action front-loaded and no filler. Phrases like 'as on the platform' are slightly imprecise, but the REST-path anchor adds precision at low cost.

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 low-complexity, 2-param mutation with no output schema, the description covers replacement semantics, the empty-array case, and the automation side effect. Return value and auth/error handling are unstated, but those are minor for this 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 coverage is 0%, so the description carries the burden. It explains tag_ids semantics well (replacement list, empty array clears all) but omits the maxItems=100 cap and says nothing about generation_result_id beyond its obvious name. Partial compensation for the coverage gap.

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

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

States a specific verb+resource: 'Replace a result's tags with tag_ids', and anchors it to the REST equivalent PUT /generation-result/{id}/tags. The resource (a generation result's tags) is distinct from siblings like mcp_update_tag (tag metadata) or mcp_add_context, but no sibling is named explicitly, so it stops short of full 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?

Implied usage is clear from 'Replace a result's tags' plus the '(empty removes all)' nuance, and 'The result viewer's tag tray' locates the effect. However, it names no alternative (e.g., mcp_update_tag) and gives no explicit when-not guidance, so the agent must infer the routing.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, and the description adds almost nothing on top of them — it never warns that this is flagged destructive, never says what gets destroyed or that tags may be removed, and never explains auth needs. The sole added detail is 'as PATCH /tag/{id}', which hints at partial-update semantics but is not elaborated.

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 first sentence is tight and front-loaded, but the second sentence is a dangling noun fragment ('The result viewer's tag tray.') that spends tokens without conveying usable instruction. Overall short, but one of the two sentences does not earn 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 destructive, idempotent mutation with three parameters at 0% schema coverage and no output schema, the description leaves major gaps: it does not explain null-field semantics, the destructive flag, or what happens on success/failure. An agent could call it, but not confidently.

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

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

Schema description coverage is 0%, so the description carries the full burden for three parameters. 'Rename or recolor' loosely maps to name and color, but it says nothing about the required tag_id, nothing about the nullable string types (can passing null clear a field?), and nothing about the 100/32 max-length constraints.

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 pair ('Rename or recolor') against a specific resource ('the company's tags') and even pins the underlying endpoint (PATCH /tag/{id}). It is clear what the tool does, though it never explicitly contrasts with siblings like create_tag or list_tags, and the trailing fragment 'The result viewer's tag tray.' adds no discriminating information.

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?

There is no statement of when to use this versus create_tag, list_tags, or mcp_workflow_tags, and no prerequisites (does the tag need to exist, does the caller need permissions). The only implicit cue is the PATCH endpoint, which a reader must interpret as 'modify an existing tag'.

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 not-read-only and idempotent, and the description goes further by explaining the mechanism behind idempotency: omitting data stores nothing and returns the receipt of the photo already stored under sha256, or stored:false. It also enumerates the receipt contents (sha256, size, stored, image_url, expiry), which no annotation provides.

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

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

Purpose is front-loaded in the first clause, then return contract, then the empty-data edge case. Dense but every sentence carries information; the parenthetical receipt list is slightly heavy but justified since no output schema exists.

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 fully specifies the return receipt fields and their downstream use, and it covers the no-data branch explicitly. An agent has everything needed to call the tool correctly and to handle both success and dedup outcomes.

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 schema already documents data, sha256 and content_type including the downscale/omit behavior. The description largely restates the no-data path rather than adding syntax, format, or cross-parameter nuance the schema lacks, so the 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 ('Store one photo dropped on the Shoot Board') plus the exact transport ('sent inline as base64') and the audience constraint ('a host that cannot upload files itself'). An agent can distinguish this from sibling uploaders without opening the schema.

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 condition that selects this tool is explicit ('for a host that cannot upload files itself'), and it routes downstream work to mcp_intake_files and mcp_commit_intake. It stops short of naming a competing sibling (e.g. upload_garment_from_public_url) as the alternative when a host CAN upload, leaving that inference to the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description's 'Read-only' largely restates that, but the 'reads items of one kind' scoping does add that it performs a single-category batch lookup rather than a general search or mutation. No return shape, ordering, or behavior on missing ids is disclosed.

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 short sentences with the purpose front-loaded and no wasted clauses. The trailing 'Read-only' is somewhat redundant against the annotations, costing a little, but the overall structure is tight and readable.

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, an undefined 'kind' parameter (no enum, no description, 0% enum coverage), and annotations that only cover the safety profile, the definition leaves a real gap: an agent cannot know which kind values are legal without trial and error. For a 3-required-param lookup tool this is under-specified.

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

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

Schema coverage is only 33% (only board_id is documented), so the description must compensate. It clarifies that kind selects a single category and ids identifies the specific items, which maps to two of the three parameters. However it never spells out the allowed kind strings or the 100-item ids cap, so the compensation is partial.

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: it reads library items of one kind by id, and gives the consumer context (the automation builder's cards). This distinguishes it reasonably well from list_* siblings and other mcp_workflow_* tools, though it never enumerates valid 'kind' values so the resource boundary stays fuzzy.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the large sibling set (mcp_workflow_gallery, mcp_workflow_tags, list_locations, etc.). Usage is only implied by the 'automation builder cards' framing, leaving the agent to infer when this beats the sibling lookups.

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 fully covered and "Read-only" in the description is largely redundant. The description does add one useful behavioral fact – that the result is a fixed enumerated set of camera views – but says nothing about return shape or ordering. Adequate against an already-strong annotation block.

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 compact sentence with the resource and its values front-loaded and no filler. The phrasing is slightly awkward ("the camera views ... a shot can use") but nothing 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 a trivial one-parameter lookup this is nearly complete, but with no output schema the description should still confirm what is returned (a list of camera-view identifiers) and whether it is scoped to the board. The value enumeration partially compensates.

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 there is a single required board_id, so the schema carries the parameter burden fully. The description adds no format or sourcing detail beyond what the schema already states, making the baseline 3 correct.

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

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

Names a specific resource (camera views) and enumerates its values (front, side, back, crops), which is enough to distinguish it from sibling list/enumeration tools like mcp_workflow_assets or mcp_workflow_tags. The verb is implicit rather than stated, but the intent 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?

"For the automation builder" implies the context in which this lookup is needed, but there is no explicit when-to-use statement, no named alternative, and no prerequisites beyond the schema's board_id. Usage is inferable rather than spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the trailing 'Read-only' adds nothing beyond structured data. The description discloses no behavior beyond that — nothing about what the contract contains, whether contract_version changes the returned shape, or how large the payload is.

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 short clauses, front-loaded with the resource identity and no filler. It is efficiently sized, though its brevity edges toward under-specification rather than tightness.

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 carry the return-value burden, yet it never explains what the contract object looks like or what contract_version selects. An agent gets safety hints from annotations but not enough to call this confidently when the optional parameter matters.

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

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

Schema coverage is 50%: board_id is described but contract_version has no description anywhere. The prose mentions neither parameter, so it does not compensate for the undocumented optional param or explain how defaulting contract_version behaves. The description adds no 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 identifies the resource — the automation format / workflow contract that the builder edits against — which hints at what is returned and distinguishes it from siblings like mcp_workflow_assets or mcp_workflow_tags. But it is a noun phrase with no verb; it never says 'returns' or 'retrieves', so an agent must infer the action. Purpose is implied rather than stated.

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?

There is no when-to-use guidance and no mention of alternatives. 'Read-only' describes a trait, not a usage condition, and the description never says when an agent should call this versus opening a board or reading another workflow_* tool. No exclusions or prerequisites are given.

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, and openWorldHint=false, so 'Read-only' in the description merely repeats structured data. The description does add that results are paginated ('one page'), but gives no information on total counts, ordering, or what happens when kind/board_id mismatch.

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 front-loaded sentence that packs purpose, scope, filters, and a read-only note without padding. The colloquial 'picker' phrasing costs a little precision but the sentence is otherwise dense and waste-free.

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 7 parameters, 14% schema coverage, no output schema, and a required 'kind' whose accepted values are never stated, the description is not complete enough for an agent to invoke this confidently. Key gaps (valid kind values, pagination limits/behavior) are unaddressed.

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

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

Schema description coverage is only 14% (just board_id), so the description must compensate but largely does not. It loosely maps 'search text, tags or category' to query/tag_ids/categories, but the required 'kind' parameter has no enum, no description, and no explanation of valid values, and page/page_size semantics are left entirely to the schema defaults.

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+resource: it returns 'one page of the user's library items of one kind,' with filtering by search text, tags, or category. This distinguishes it as a paginated, filtered library listing. However, it does not name or contrast against the many sibling list_* and search_uwear_library tools, and the central discriminator ('kind') is never explained.

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

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

'The automation builder's picker' implies the usage context (during automation building) and the filter dimensions imply when each filter applies. But there is no explicit when-to-use vs. when-not, and no pointer to alternative tools like search_uwear_library or the sibling list_* tools. Usage is only implied.

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 only behavioral claim, 'Read-only', merely restates the readOnlyHint/destructiveHint annotations that the agent already receives. No additional context is offered about what the categories are, how they are scoped to the board, or whether results are cached or stable. No contradiction with annotations, but essentially no value added 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 short sentences with no filler, and the purpose is front-loaded. However, the extreme brevity comes at the cost of substance rather than being efficient conciseness, so it lands at minimum-viable rather than strong.

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

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

For a one-parameter, read-only tool with annotations covering safety and no output schema, the description is adequate but thin: it never indicates the form of the returned categories (names? objects? board-scoped?), which the agent needs to wire them into a filter.

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

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

Schema coverage is 100% for the single board_id parameter, and the schema description already explains where to obtain it ('from Open Shoot Board or your context'). The description adds nothing about the parameter, 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?

Identifies the resource (garment categories) and its intended consumer (the automation builder's category filters), but never states the verb — that it lists or returns them. A reader can infer a read/list tool, and it is distinguishable from sibling list_garments, but the phrasing is noun-fragment rather than a clear action statement.

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?

'For the automation builder's category filters' hints at one use case, but there is no explicit when-to-use guidance, no mention of prerequisites, and no differentiation from closely related siblings such as mcp_workflow_tags or mcp_workflow_cameras.

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, destructiveHint=false and openWorldHint=false, and the description's 'Read-only' merely restates that. Its one additive contribution is the scope context ('the account's tags, for the automation builder's tag filters'), which tells the agent which consumer the data serves. No return format or pagination behavior is disclosed.

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 short sentences with no padding, though the opening noun phrase is less front-loaded than a verb-first statement would be and the trailing 'Read-only.' fragment is redundant with the annotations. Efficient overall but with a little wasted signal.

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 low-complexity one-parameter tool with no output schema, the description identifies the resource and scope, but it never describes what the returned tag objects contain or how they are ordered/filtered. Annotations cover safety, so the remaining gap is modest rather than critical.

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