mu

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

With no annotations provided, the description carries full burden and does an excellent job: it explains the auth requirement ('Authorization: Bearer <api_key>'), commission details (10% within 30 days), return fields (clicks, sales, earned_jpy, mu_credit_balance), and usage of ref_param. No contradictions.

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

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

The description is concise (approximately 70 words) and front-loaded with the primary purpose. Every sentence adds value: main function, benefit, usage, return fields, and auth. No redundant or vague phrasing.

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

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

For a simple parameterless getter with no output schema, the description is complete: it explains what the tool returns, how to use the results, and the auth requirement. No gaps remain given the low complexity.

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

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

The input schema has zero parameters, so baseline is 4. The description adds no parameter information (none needed) but does not detract. It correctly notes the tool requires no arguments.

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 retrieves the user's personal MU affiliate link and stats, with a specific verb ('Get') and resource ('MU affiliate link'). It distinguishes from siblings by focusing on affiliate functionality, which is unique among the listed tools.

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

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

The description implies when to use (when needing affiliate link/stats) but provides no explicit guidance on alternatives or when not to use. It lacks comparison with sibling tools, such as mu_check or mu_status, which might handle other retrieval needs.

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 no annotations provided, the description carries full burden. It states the tool is read-only, requires no API key, and describes the return structure (ok, kind, report with ok, gaps, actions). Missing details on error handling but sufficient for most scenarios.

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

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

The description is a single, well-structured paragraph of four sentences. It front-loads the core purpose, lists key parameters, gives return type, and ends with usage advice. No unnecessary words.

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

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

For a tool with 11 parameters and no output schema or annotations, the description covers the essential: purpose, inputs, output shape, and usage context. It lacks details on error handling or edge cases, but overall is complete enough for effective use.

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 low (36%), but the description compensates by explaining the purpose of each parameter, the relationship between spec JSON and individual attributes, and how region triggers legal checks. This adds significant value beyond the schema.

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

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

The description clearly states the tool checks spec, legal/compliance, and supplier requirements for a planned make. It distinguishes from siblings by explicitly naming mu_create_product and mu_rfq_create as tools to use after this check.

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 advises using this tool before mu_create_product or mu_rfq_create, provides usage context (read-only, no API key), but does not exhaustively list when not to use it or cover all sibling alternatives.

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

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

No annotations provided, so the description carries full burden. It discloses that products go live immediately for trusted owners unless the risk gate trips, requiring MA-council review. It also specifies the need for an Authorization header and the importance of checking the `status` field in 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?

The description is lengthy but every sentence adds value. It front-loads the main purpose and then systematically covers special cases and constraints. Could be slightly more concise, but it is well-structured and informative.

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

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

Given the tool's complexity (12 parameters, nested objects, many product kinds), the description is thorough. It covers mandatory fields, artwork options, special handling for various kinds, the risk gate, authentication, and response handling. No output schema exists, but the description compensates adequately.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema, e.g., explaining the mutual exclusivity of `design_url` and `ai_prompt`, detailing `phone_case` behavior, and providing special instructions for `event_ticket` and `song` kinds, as well as the `position` object 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 action ('Create a product') and the resource ('in one of your MU stores'). It distinguishes this tool from siblings like mu_update_product and mu_retire_product by specifying creation context. The verb 'Create' and resource 'product' are explicit.

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

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

The description provides explicit guidance on when to use `design_url` vs `ai_prompt`, and explains special cases for `phone_case`, `event_ticket`, `song`, and other digital/manual-fulfillment kinds. It also mentions the risk gate and the need to report the `status` field. It does not explicitly list when not to use the tool, but the context is clear.

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

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

No annotations provided, so description carries full burden. It discloses auth requirements and return values, but does not mention side effects (e.g., whether creation is immediately visible, if there are limits, or if it triggers downstream processes). Adequate but not exhaustive.

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

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

Two sentences, zero waste. Front-loaded with purpose, immediately followed by return info and auth requirement. Highly concise 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?

Given no output schema and no annotations, the description covers purpose, return values, authentication, and parameter scope. Could be more complete by detailing error conditions (e.g., duplicate slug), but overall sufficient for an agent to use the tool.

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

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

Schema coverage is 100% with clear descriptions for each parameter. The description adds no per-parameter details beyond what's already in the schema, meeting the baseline. No extra semantic value.

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

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

Description clearly states the action ('Open a new MU store') and resource ('branded storefront'), and specifies the return values (slug and store_url). Among many sibling tools, this is uniquely about store creation.

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 notes requirements (agent account, Authorization header) and implies usage context. It does not explicitly contrast with alternatives, but no sibling tool directly competes. Lacks exclusion criteria (e.g., when not to use).

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

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

With no annotations, the description fully discloses behavior. It explains the meaning of status values (ok, low, request, missing) and consent values (yes, requested, no). It defines the derived field ready_to_print and the action rule for sending to ISAMI. This is comprehensive and exceeds typical transparency.

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

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

The description is a single, dense sentence that packs all necessary information without redundancy. While it is long, it efficiently conveys all key details. It is front-loaded with the main action and then provides specifics.

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

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

Given no output schema, the description fully documents the return fields and their meanings. It explains the condition for ready_to_print and the correct usage. The tool's purpose and output are completely covered for its scope.

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 no parameters (0 params, 100% schema coverage), so the baseline is 4. The description doesn't need to add parameter details. It correctly focuses on output and behavior instead.

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

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

The description clearly states the tool lists sponsored gi's sponsor placements with specific fields like slot, brand, position, etc. It specifies 'owner-only' restriction, distinguishing it from other tools. The verb 'list' with the specific resource 'sponsored gi's sponsor placements' makes the purpose unambiguous.

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

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

The description explicitly states it's owner-only, guiding who should use it. It provides a critical usage guideline: 'ready_to_print is true ONLY when status=ok AND consent=yes — anything else must NOT be sent to ISAMI.' This gives clear when-to-use and when-not-to-use advice, including a warning about trademark misuse.

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 no annotations, the description must fully disclose behavior. It correctly identifies authorization (owner-only) and the fields that can be changed, but does not mention side effects, validation, or concurrency. Adequate but not comprehensive.

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 40-word sentence that front-loads the main action and efficiently covers purpose, resource, and allowable modifications. No unnecessary words.

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

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

The description and schema together cover parameters well, but the tool has no output schema and the description omits return behavior (e.g., success indication). For a mutation tool, this is a gap. Adequate but not 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% with detailed descriptions (e.g., consent values). The description summarizes the actions (swap, set status, add note) but adds little 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?

The description clearly states the tool updates a gi sponsor placement by slot, listing specific modifiable fields (logo_url, status, note) and constraints (owner-only). This distinguishes it from siblings like mu_gi_logos (list slots) and mu_gi_request_logos (request logos).

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

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

The description implies usage after retrieving slots via mu_gi_logos and notes owner-only restriction, but does not explicitly state when not to use the tool or compare with alternatives like mu_gi_request_logos. Guidance is present but implicit.

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 no annotations, the description discloses key behaviors: owner-only access, generates drafts only, does not send, and specific request content. Does not mention side effects like overwriting existing drafts, but for a 0-parameter tool, this is sufficient.

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?

Extremely concise: two sentences cover purpose, condition, content, exclusions, and follow-up action. No filler, front-loaded with the main action.

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 zero parameters and no output schema, the description fully covers what the agent needs: target sponsors, draft content, what not to expect, and next steps. References sibling tool for recording consent, providing complete workflow context.

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

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

No parameters exist, so baseline score of 4 applies. The description does not need to add parameter info as the schema is already complete and empty.

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

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

Description clearly states the tool generates draft emails for logo permission requests from sponsors without consent. It specifies the request content (written permission and vector logo) and distinguishes itself by being owner-only and not a sending 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?

Explicitly says when to use: for sponsors whose consent is not 'yes'. Provides after-action guidance to use mu_gi_logo_set to record permission. Also clarifies it does not send emails, setting expectations correctly. Could be improved by mentioning when not to use, but still effective.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states 'Owner-only' but does not describe side effects, authentication requirements, response format, or what happens if accessed by a non-owner. The disclosure is minimal.

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 front-loaded key information (returns URLs, owner-only). Every sentence adds necessary detail without redundancy. Highly concise and 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?

Given no output schema, the description should clarify the output format (e.g., structure of returned URLs). It mentions specific URL types but does not indicate how they are returned. The PDF location is noted, but overall completeness is adequate yet lacks output detail.

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

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

The input schema has no parameters, so schema description coverage is 100%. With zero parameters, the baseline is 4. The description does not need to add parameter semantics, but it could mention that no arguments are required.

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 returns URLs for the public page and lifestyle/mockup images (front/back/crest/QR) and mentions a PDF location. The title reinforces the purpose and ownership restriction. It is distinct from sibling tools like mu_gi_logos which handle logos.

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 mentions 'Owner-only' indicating a usage constraint but does not provide explicit guidance on when to use this tool versus alternatives, nor does it specify prerequisites or exclusions beyond the owner restriction.

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

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

No annotations provided, so description carries full burden. It discloses the read-only nature (listing) and required authorization, but lacks details on pagination, rate limits, or potential side effects. The description is adequate but not rich in behavioral context.

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

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

Two sentences: first enumerates returned fields, second gives auth. No filler, efficient, and front-loaded with the most important 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 tool with no parameters and no output schema, the description provides a clear list of output fields and auth requirement. It is complete enough for an agent to understand the tool's purpose and usage, though an output schema would further help.

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?

Input schema is empty with 0 parameters, and schema description coverage is 100% (trivially). The description adds no parameter info, but none is needed. Baseline is 4 as per guidelines when schema already covers 100% of parameters.

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

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

The description states 'List every product you have created across your MU stores' with specific fields (sku, store, label, etc.), clearly identifying the action and resource. It distinguishes from sibling tools like mu_create_product, mu_update_product, and mu_retire_product by focusing on listing own products.

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

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

The description implies usage for listing the user's own MU products, but does not explicitly state when to use this tool vs siblings like mu_rfq_list or mu_ship_orders. The auth requirement is noted, but no alternatives 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?

With no annotations, the description fully discloses no creation, no cost, no credit usage, durable image URL, rate limit of 30/hour, and required Authorization header. It also explains the two rendering sources (Printful vs. card) and the polling mechanism for 'processing' status.

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 somewhat lengthy but well-structured, front-loading the core purpose and covering cost, rendering, WYSIWYG, timing, rate limit, and auth. Every sentence adds value, though a minor trim could improve conciseness.

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

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

With 4 parameters, no output schema, and no annotations, the description is exceptionally complete. It explains the two possible return states (status='processing' or image URL), the WYSIWYG concept, rate limiting, auth requirements, and ties to sibling tools (mu_create_product, mu_upload_design). No missing critical information.

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 descriptions cover all 4 parameters (100% coverage), but the description adds crucial context: the position parameter is only for front-print DTG apparel, the design_url should first be uploaded via mu_upload_design, and preview_id is for continued waiting. It also explains the 'kind' parameter's rendering behavior (Printful vs. card).

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 ('preview') and resource ('mockup'), emphasizing it happens before creation and is cost-free. It differentiates from siblings like mu_create_product by explicitly contrasting preview vs creation and linking the 'position' parameter for WYSIWYG consistency.

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 advises using this tool before creating a product, and explains when to use preview_id for polling. It implies alternatives (mu_create_product for actual creation) but doesn't explicitly state when not to use it. The WYSIWYG link provides strong contextual guidance.

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

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

With no annotations, description fully covers behavioral traits: states read-only (creates nothing), explains output ranking (buyable-now first), discloses that no API key is needed, and describes mode-dependent follow-up actions.

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?

Description is a single paragraph of moderate length. It is front-loaded with purpose and output, but could be slightly more structured. However, every sentence adds value, so the length is justified given the complexity.

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 lacking an output schema, description explains the returned data (supplier, price, MOQ, lead time, route, mode) and the ranking logic. It also provides complete flow guidance for next steps, making the tool 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?

All 5 parameters have schema descriptions (100% coverage). Description adds extra meaning: for 'kind' lists specific examples and notes inference from description; for 'qty' mentions MOQ checking; for 'budget' flags within_budget; for 'region' says prefers matching suppliers.

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

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

Description states specific verb (ask/quote) and resource (manufacturing router). Clearly distinguishes from siblings like mu_create_product and mu_rfq_create by positioning it as a pre-creation step and specifying follow-up actions for auto vs. quote modes.

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 says 'before you create a product' and provides when-not-to-use by describing when to use mu_create_product (if mode is auto) and when to human RFQ (if quote). Also notes read-only nature and no API key required.

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

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

Discloses that a 6-digit verification code is emailed and that no authentication is needed. With no annotations, this covers key behavioral aspects, though additional details (e.g., idempotency, rate limits) are absent.

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 wasted words. The action is front-loaded, and the flow is concisely described.

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 registration initiation tool with no output schema, the description adequately covers the complete flow, next steps, and authentication requirements.

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 does not add significant meaning beyond what the schema already provides for the two parameters.

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

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

The description clearly states the action (start MU agent registration) and the resource (email address). It distinguishes itself from the sibling mu_verify by outlining the two-step registration flow.

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 instructs to call mu_verify after receiving the code, and notes that no authentication is required. This provides clear when-to-use and next steps.

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 no annotations, the description carries full burden. It reveals the effect (status=retired, removed from storefront) but does not discuss reversibility, side effects, or related data impacts. 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 two efficient sentences with no wasted words. It front-loads the main action and follows with necessary preconditions.

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

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

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is sufficiently complete. It explains purpose, preconditions, and effect, though it lacks detail on return value or error scenarios.

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 parameter sku is fully documented in the schema (100% coverage). The description adds the condition 'must belong to one of your stores', providing extra context beyond the schema description.

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

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

The description clearly states that it retires a product by setting its status to 'retired' and removing it from the storefront, using a specific verb and resource. This distinguishes it from siblings like mu_update_product, which likely handles other updates.

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

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

The description provides explicit usage conditions: owner-only and requires authorization header. However, it does not mention when not to use this tool or suggest alternatives, such as using mu_update_product for other status changes.

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

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

No annotations provided, so description must cover behavioral traits. It discloses the draft is saved as 'drafted', scoped to user's account, and that the router resolves supplier. Lacks details on idempotency, error handling, or return value.

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

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

Three sentences, each earning its place. Front-loaded with purpose, followed by key behavior, then parameter summary. No redundancy or filler.

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

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

Covers core functionality, parameter usage, and scope. Lacks explanation of return value or error cases, but adequate for a creation tool with good schema coverage.

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

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

Schema coverage is 88%, and description adds context beyond schema: explains that supplier_id OR kind/description can be used (router resolves), and that spec_id is from mu_spec_draft. Adds meaningful guidance for parameter selection.

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 drafts an RFQ without sending, using verbs like 'Open a quote request' and 'Generates a ready-to-send draft'. It distinguishes from siblings like mu_rfq_list (listing) and mu_rfq_record (recording) by focusing on creation.

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

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

Explicitly states the tool does not send, indicating when to follow up with outbound mail/PO. Provides guidance on using supplier_id or kind/description to resolve supplier. However, it does not explicitly differentiate from mu_quote or other related 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?

No annotations provided, and the description only mentions scoping. It lacks details on side effects, pagination, ordering, or limits, leaving the agent uncertain about behavioral traits.

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

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

Two concise sentences with front-loaded action and filters. Every sentence adds value without redundancy.

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

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

Covers essential information for a simple list tool, but omits pagination, sorting, response format, and error handling which are relevant for completeness.

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

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

Schema coverage is 0%, but description explains all three parameters (supplier_id, kind, status) and their role, including status enum values, compensating well for missing schema descriptions.

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

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

The description clearly states the verb 'List' and the resource 'RFQs', includes key filters, and distinguishes from sibling tools like mu_rfq_create and mu_rfq_record.

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 specifies RFQs are scoped to your account (admin sees all), giving clear context. It could explicitly mention alternatives but still provides enough guidance.

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

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

With no annotations, the description conveys key behaviors: status values, requirement for quoted_unit_jpy when received, and the reflection into mu_quote's est_unit_jpy for valid received quotes. Account scoping is mentioned. It lacks details on idempotency or side effects for other statuses, but overall provides solid transparency.

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

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

The description is two sentences, front-loaded with the primary action, and every phrase adds value. No unnecessary words or repetition of schema details. Excellent conciseness.

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

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

Given 7 parameters, no output schema, and the reflection behavior, the description covers the main use case but omits details on the return value, handling of other statuses (sent/expired), and the note parameter. It is adequate for basic usage but could be more thorough.

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 57% (4 of 7 parameters described). The description adds context for quoted_unit_jpy (required when received) and valid_until (ISO date), and mentions moq/lead_time_days without extra detail. No value added for note or other parameters. At moderate coverage, the description partially compensates but does not fully cover all parameters.

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

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

The description clearly states the tool records a supplier's RFQ reply with specific fields. It mentions the context 'after a factory replies', which distinguishes it from RFQ creation or listing tools. However, it does not explicitly differentiate from siblings like mu_rfq_create or mu_rfq_list, thus a 4 is appropriate.

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

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

The description provides clear timing ('after a factory replies') and conditions (status set to received requires quoted_unit_jpy). It hints at when to use but does not explicitly state when not to use or list alternatives among many siblings. The reflection behavior gives context, but missing exclusion guidance prevents a higher score.

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

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

With no annotations provided, the description carries the full burden. It reveals the return structure (per-store, totals, 50 recent orders) and authentication requirement, but does not mention potential limitations like pagination, error handling, or rate limits. A score of 3 is appropriate as it adds value beyond the empty schema but lacks behavioral depth.

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

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

Two sentences: first delivers the core purpose and data details, second adds the authentication requirement. No useless words, front-loaded, and 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?

Given no output schema and no parameters, the description provides a complete picture: what data is returned (per-store/totals/recent orders with fields) and how to authenticate. It is sufficient for a simple read operation, though more detail on data semantics could improve it.

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

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

The tool has 0 parameters with 100% schema coverage. The baseline for zero parameters is 4. The description does not need to add parameter info, and it correctly focuses on the output.

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

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

Description clearly states the tool gets sales for MU stores, specifying the data provided: per-store and total order_count/revenue_jpy, plus 50 recent orders with specific fields. This distinguishes it from sibling tools like mu_check or mu_quote which serve different purposes.

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

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

The description indicates when to use (to retrieve sales data) and mentions the required authentication. It does not explicitly exclude alternatives, but the context and specificity make its usage clear. There are no sibling tools competing for this exact function.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return format (filename, csv_utf8, csv_shift_jis_base64) and the requirement to use Shift_JIS for import. It also states 'Owner-only,' indicating access control. It does not mention any side effects (e.g., marking orders as shipped), but given the tool generates a CSV without modifying state, this is acceptable.

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

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

The description is concise with no wasted words. It front-loads the core action ('Generate a 送り状 CSV for all un-shipped orders'), then efficiently covers the format, prerequisites, and return structure. Every sentence adds value.

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

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

Given the simple input (one optional parameter) and no output schema, the description fully covers what the tool does, its return value, and important context (owner-only, first-time registration). No gaps remain for effective agent 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% for the single 'courier' parameter with an enum and description. The tool description adds context by naming the specific courier systems (ヤマト B2クラウド and 佐川 e飛伝) beyond the schema's brief description, but this is incremental. 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 title and description clearly state the tool generates a shipping-label CSV for un-shipped orders for two specific couriers. It distinguishes itself from sibling shipping tools (e.g., mu_ship_import_tracking, mu_ship_mark, mu_ship_order) by focusing on CSV generation.

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

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

The description explicitly states the CSV is for all un-shipped orders, specifies the two courier formats, and notes that no carrier API/contract is needed. It also advises first-time registration of the column layout. However, it does not explicitly mention when not to use this tool or provide alternative tools for other scenarios.

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

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

No annotations provided, so description carries full burden. Discloses that it matches MU-{id} to orders, sets tracking, marks shipped, and is owner-only. Does not cover idempotency, error handling, or potential side effects, but adequately describes the core behavior for a bulk import tool.

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

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

Three sentences, no wasted words. Front-loaded with action ('Paste the CSV'), then explains effect and counterpart. Perfectly concise for the information conveyed.

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

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

Given the tool's simplicity (2 params, no output schema), description covers all key aspects: source, format, purpose, ownership, and relationship to sibling. Missing details like return behavior or prerequisites (e.g., needing to have used mu_ship_csv first) but adequate for an agent.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning by specifying the CSV source (B2クラウド/e飛伝) and explaining the matching logic. For the courier parameter, enum values are clear. Adds moderate value beyond schema.

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

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

Clearly states it imports courier tracking numbers from a specific CSV produced by B2クラウド/e飛伝, explains the content (MU-{id} and 送り状番号), and the effect (matches to orders, sets tracking, marks shipped). Distinguishes from sibling mu_ship_csv as its 'natural counterpart'.

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

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

Explicitly states when to use: after issuing labels, paste the CSV. References the counterpart mu_ship_csv, implying sequential usage. Lacks explicit when-not-to-use or alternative scenarios but provides clear context.

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

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

No annotations are provided, so the description carries the full burden. It discloses the main behavior (advancing status, recording courier/tracking when shipping) and access control. However, it omits details like error handling, side effects (e.g., email send behavior beyond the parameter), and constraints on status transitions.

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 concise sentences: first states the core action, second notes access control, third lists valid statuses. Every sentence adds value with no redundancy or fluff.

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

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

The description covers the essential behavior and constraints. However, it lacks information about return values, error cases, or prerequisites (e.g., order must exist). Given the absence of an output schema, more context could help an agent understand what to expect after 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%, so the schema already documents parameters well. The description adds context about when courier/tracking are required (when status=shipped) and explains the notify parameter's purpose and default. This is useful but not extensive; 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 it advances ship_status and records courier/tracking, specifying the resource (physical order) and action. It lists valid statuses. However, it does not explicitly distinguish from sibling tools like mu_ship_order or mu_ship_import_tracking, which could lead to confusion.

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 mentions 'Owner-only' and the required status values, giving some context on when to use. It does not explicitly state when not to use it or list alternatives among siblings, leaving room for ambiguity.

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 no annotations, the description covers key behaviors: address/phone masking controlled by reveal parameter, and ownership restriction. Missing details on error handling or idempotency, but main traits are 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 concise sentences that front-load the purpose and immediately add critical behavioral context. No unnecessary 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?

Given the simplicity of the tool (2 params, no output schema), the description covers all essential aspects: what is returned, masking behavior, access control. Could mention error handling, but not required for basic usage.

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

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

Schema coverage is 100% with good descriptions. The description adds minimal extra meaning beyond 'by id' and 'masked unless reveal', essentially reinforcing 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?

Clearly states it fetches a single physical order by ID, with specific fields (status, courier, tracking). This distinguishes it from list tools like mu_ship_orders.

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?

Specifies 'Owner-only' as a prerequisite but does not explicitly describe when to use versus alternatives. However, the name and context make it clear for single order retrieval.

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 no annotations provided, the description carries the full burden. It discloses the auth requirement (Bearer token, 403 otherwise) and mentions the output includes status, courier, and tracking. However, it does not state whether the operation is read-only, idempotent, or if there are any side effects. More behavioral context would be beneficial.

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

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

The description is extremely concise: one main sentence plus a brief owner-only clarification. Every sentence provides essential information without extraneous detail. The most critical information (what, for whom, auth requirement) is front-loaded.

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

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

Given the tool's simplicity (2 boolean params, no output schema, no annotations), the description covers the purpose, parameters with usage advice, and auth requirement. It mentions the fields returned (ship_status, courier, tracking) but does not specify the exact response structure (e.g., array of objects). For a list tool, a note on pagination or sorting would be helpful but is not critical given the simple nature.

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

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

The schema already has 100% coverage with descriptions for both parameters. The tool's description adds significant value by explaining the default behavior for 'all' (active only) and importantly for 'reveal' it cautions about PII sensitivity ('customer PII stays out of the chat log'), guiding appropriate usage. This exceeds the schema's basic descriptions.

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

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

The description clearly states the action 'List' and the specific resource 'physical (address-bearing) orders for the factory shipping console'. It also specifies the returned fields (ship_status, courier, tracking) and the access restriction (owner-only), leaving no ambiguity about what the tool does. The title reinforces this by mentioning 'owner only'.

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

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

The description indicates the tool is for the 'factory shipping console' and is owner-only, implying it's for administrative use. However, it does not explicitly state when to use this tool versus its siblings (e.g., mu_ship_csv, mu_ship_mark) or provide conditions for alternative selection. More explicit guidance would improve usability.

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 no annotations, the description carries full burden. It discloses missing fields behavior, follow-up next_question, API key requirement, and AI budget usage. No contradictions. Could add clarity on whether any state is modified, but overall transparent.

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

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

Three concise sentences: core purpose, missing field behavior, and integration/dependency. Every sentence adds value; no redundancy or filler.

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

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

Given one input and no output schema, the description covers input style, output behavior (missing fields, next_question), and integration with mu_rfq_create. It mentions spec_id implicitly. Could explicitly state output format, but it's adequate.

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

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

Schema coverage is 100% for the single parameter 'prompt'. The description adds an example and clarifies the type of input (free-text request for manufacturing spec), providing context beyond the schema's brief description.

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

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

The description clearly states it converts natural language into a structured manufacturing spec, listing fields (kind, material, dimensions, etc.). This distinguishes it from siblings like mu_rfq_create, which use the resulting spec_id.

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

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

Explicitly instructs to feed the resulting spec_id into mu_rfq_create, and notes the prerequisite of an API key (register/verify first). This provides clear when-to-use guidance and connects to a sibling 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?

No annotations provided, so the description carries full burden. It correctly indicates a read operation ('Get') and lists returned data. It does not mention side effects or rate limits, but for a simple profile tool this is acceptable.

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

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

Single, well-structured sentence that front-loads the action and efficiently lists specific fields. No extraneous 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?

Given zero parameters and no output schema, the description covers the essential information: what the tool returns and an auth requirement. It lacks details about error handling or response format, but these are minor for such a simple 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?

There are no parameters in the schema (100% coverage by default). Baseline is 3. The description adds no parameter info, but mentioning the auth header is peripheral to parameter semantics.

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

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

The description explicitly states it retrieves the authenticated agent's profile and enumerates key fields (email, credits, flag, stores, limits). This clearly distinguishes it from sibling tools like mu_list_mine or mu_check.

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 specifies a prerequisite (Authorization header). As a profile retrieval tool, its usage context is obvious, but it could explicitly mention that it is for the currently authenticated agent only, though 'authenticated agent's profile' implies as much.

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 no annotations, the description carries the burden. It mentions the feedback lands in a triage queue and requires authorization. However, it does not detail other behavioral aspects like whether the operation is idempotent, if confirmation is given, or rate limits. For a feedback tool, 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 three sentences with no redundancy. It front-loads the invitation to submit, lists use cases, and ends with destination and authentication requirement. Every sentence serves a purpose.

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

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

For a simple feedback tool with 5 parameters and no output schema, the description covers use cases, destination, and auth. It could mention that it's a write operation or confirm that a feedback is created, but it is largely complete.

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

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

Schema coverage is 100%, so the schema already describes each parameter. The description reiterates some uses (e.g., 'title' as short summary) but adds no new semantic meaning beyond the schema definitions.

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

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

The description clearly states the tool is for filing bugs, suggesting improvements, or requesting features. It specifies usage scenarios like platform/API misbehavior or product issues, and there are no sibling tools with overlapping 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 explicitly tells when to use the tool (bug, improvement, feature request) and where the feedback lands (MA-council triage queue). It does not provide explicit exclusions or alternatives, but the context is sufficient given the lack of similar 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?

Given no annotations, the description fully informs about behaviors: price clamping, position triggering re-render, immutable Printful IDs, owner-only access, and auth requirement. Also warns that mockup preview should be used before applying position changes.

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

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

Single paragraph, front-loaded with the core action, then efficiently lists constraints and fields. Every sentence adds important information without redundancy.

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

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

Covers all key aspects: allowed states, modifiable fields, constraints, auth, and refers to preview mockup tool. No output schema, but return values are not critical. Minor confusion with 'before creating' instead of 'before updating' but still adequate.

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

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

Schema has 100% description coverage, so baseline is 3. The description adds value by explaining price clamping ('clamped up to the kind's floor'), position triggering re-render, and that design_url must be absolute https. These details go beyond schema.

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

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

The description clearly states 'Update one of your products' and specifies the allowed states ('review' or 'retired'), distinguishing it from create and retire tools. It lists the updatable fields, making the purpose unambiguous.

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

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

Explicitly says 'Allowed ONLY while the product is in review or retired' and 'Owner-only. Requires Authorization: Bearer <api_key>.' Implicitly indicates when not to use (not on live products) but does not explicitly name alternatives.

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

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

With no annotations provided, the description carries full burden. It discloses the input constraints (PNG format, base64 encoding, size limit), authentication requirement, and return type (durable URL). It does not cover error behavior or rate limits, but for a straightforward upload tool, the key behaviors are adequately covered.

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

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

The description is two sentences, highly efficient, and front-loaded with the core action. Every sentence adds essential information with no fluff or repetition.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description is complete. It explains the input, constraints, output (durable URL), and how to use the output with a sibling tool. No additional information is necessary for this context.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that 'filename' is 'informational only' and that 'data_base64' may include an optional prefix, which goes beyond the schema's description. This helps the agent understand parameter usage better.

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 (upload a PNG design), the input format (base64-encoded, <=3MB), and the output (durable https URL). It also explicitly links to the sibling tool 'mu_create_product' by specifying how to use the returned URL as the 'design_url' parameter, distinguishing this tool from others.

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

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

The description provides clear context for when to use the tool (to obtain a URL for product creation) and specifies the required authentication header. However, it does not explicitly state when not to use it or mention alternatives, which would enhance guidance further.

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 no annotations provided, the description fully carries the burden. It discloses that no authentication is needed for this call and explains the output (api_key) and its usage, which is critical for the agent.

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

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

Two concise sentences, front-loaded with action. No wasted words; every sentence adds value.

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

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

For a simple tool with two parameters and no output schema, the description covers all essential aspects: purpose, input constraints, output, and follow-up usage. It is complete.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds value by specifying '6-digit code' and clarifying 'email used in mu_register', providing context beyond the schema.

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

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

The description clearly states the tool verifies a 6-digit code from mu_register and returns an api_key. It distinguishes itself from sibling tools like mu_register by specifying the verification step.

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

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

The description explains when to use it (after receiving code from mu_register) and how to use the resulting api_key for subsequent calls. It lacks explicit alternatives or exclusion cases, but the context is clear.

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