mu

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

With no annotations, the description fully discloses behavior: it returns clicks, sales, earned_jpy, and mu_credit_balance, explains the 30-day window and 10% commission, and specifies the required authorization header.

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: first states the purpose, second details the mechanism, third lists outputs and auth. Front-loaded and efficient with 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?

Given the tool's simplicity (0 parameters, no output schema), the description is complete. It explains what is returned, how the referral works, 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?

No parameters exist (input schema is empty with 100% coverage), so the description does not need to add param info. Baseline score of 4 is appropriate as the description adds overall context but no parameter-specific details.

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

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

Clearly states the tool retrieves the user's personal MU affiliate link and stats. The verb 'Get' and resource are specific, and the tool is distinct from siblings like mu_sales or mu_create_product.

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?

Explains that the tool is used to obtain a referral link for sharing, and describes the commission structure and ref_param. Implicitly indicates when to use, but does not explicitly state when not to use or mention alternatives, though none are needed given the tool's unique purpose.

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

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

No annotations are provided, so the description shoulders the burden. It correctly labels the tool as 'Read-only, no API key,' which discloses the safety profile. It also describes the return structure, including { ok, kind, report: { ok, gaps[], actions[] } }. However, it doesn't mention potential limitations like rate limits or input size constraints, which would be nice but not critical.

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 very concise (three sentences) yet packs a wealth of information: purpose, parameters, return format, and usage guidance. It front-loads the primary action ('Ask the MU requirements engine') and organizes examples logically. No extraneous words; 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?

Given no output schema, the description fully covers the return structure. With 11 parameters, it clearly explains how to provide input (spec vs individual attrs). It mentions regional legal triggers and supplier order term checks. It also positions the tool relative to key siblings (mu_create_product, mu_rfq_create). This is complete for a specialized check tool.

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

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

The input schema covers only 36% of parameters with descriptions. The description adds significant meaning: it categorizes parameters into spec floor, legal flags, and supplier terms. It explains the two modes for providing spec (JSON string 'spec' or individual attributes like material, dimensions, etc.). It also gives examples like 'jp' for region and 'isami_gi' for supplier_id, adding practical context 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 the core purpose: checking requirements for a make including spec, legal/compliance, and supplier terms. It uses specific verbs ('Ask the MU requirements engine') and lists distinct domains. It distinguishes from sibling tools by mentioning 'Use before mu_create_product or mu_rfq_create.'

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 this tool ('Use before mu_create_product or mu_rfq_create') and implies it's a prerequisite check. It also notes it's read-only and doesn't require an API key, setting expectations for safe, non-destructive usage. No explicit when-not but the 'before' phrasing 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 provided, so description carries full burden. It discloses artwork costing mu_credits for AI gen, product going live immediately for trusted owners unless risk gate trips, and to always report status field. It describes behavior for digital kinds (emailing links) and manual fulfillment, and phone_case 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?

The description is long but well-structured: first sentence states purpose, then artwork options, kind list, special kinds, behavior after creation. Every sentence is necessary given the complexity, but could be slightly more concise.

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 complexity (12 parameters, nested objects, many kinds with special cases), description covers most aspects: risk gate, status field, authorization, references to other tools (mu_status, mu_preview_mockup). No output schema, but description explains response behavior (status field). Complete.

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

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

Schema description coverage is 100% (baseline 3). The description adds extra context: distinction between design_url and ai_prompt, phone_case behavior, extra fields for event_ticket and song, and print placement for certain kinds. This adds 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?

The description clearly states 'Create a product in one of your MU stores' and provides specific details about artwork options, kinds, and special cases. It distinguishes from sibling tools like mu_update_product and mu_upload_design 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?

The description gives explicit guidance on when to use each artwork parameter (exactly one of design_url or ai_prompt), which kinds require extra fields (event_ticket, song), and mentions the risk gate and review process. It includes authorization requirement but does not explicitly state when not to use this tool versus alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the authentication requirement and return values, but it does not mention side effects, reversibility, rate limits, or error conditions. For a creation tool, more behavioral context would be helpful.

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

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

The description is two sentences long, front-loading the purpose and then providing return value and auth requirement with no redundancy. 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 complexity (5 params, no output schema), the description covers purpose, return values, and authentication. It lacks details on validation or error handling, but is adequate for a creation tool with clear input 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%, meaning the input schema already describes all parameters adequately. The tool description adds no additional parameter guidance beyond what is in 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 verb 'Open a new MU store', specifies the resource (branded storefront), and distinguishes from sibling tools like mu_create_product by focusing on store creation. It also mentions the return values (slug and URL).

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 when-to-use context by defining the action and result. It includes a prerequisite (Authorization header). However, it does not explicitly mention when not to use this tool or suggest alternatives from 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?

No annotations are provided, so the description fully bears the burden of behavioral disclosure. It transparently describes the output fields and the crucial logic for ready_to_print, including a clear warning about trademark misuse and the requirement for consent. This exceeds basic expectations.

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 covering all attributes and logic. While it packs a lot of valuable information, it could be slightly more structured (e.g., bullet points) for easier scanning. It is efficient overall.

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 input parameters and no output schema, the description must fully explain the tool's behavior. It does so by enumerating all returned fields, the status values, and the critical ready_to_print condition. The warning about trademark misuse adds essential context. It is complete for the tool's complexity.

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

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

The tool has zero parameters, and schema coverage is 100% (no params to document). The description adds meaning by detailing the tool's return data and logic, compensating for the absence of an output schema. A score of 4 is appropriate as baseline is 4 with no params.

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

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

The description specifies the tool lists specific gi sponsor placements with detailed attributes like slot, brand, position, size, thread color, file, status, and consent. It clearly distinguishes itself by focusing on sponsor logos with status and consent checks, differentiating from sibling tools like mu_gi_logo_set (likely a setter) and mu_list_mine (generic list).

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 clarifies it is owner-only and explains the critical ready_to_print condition, guiding correct usage. It doesn't explicitly state when not to use or list alternatives, but the context is clear for its specific purpose.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the 'Owner-only' authorization constraint and the mutation nature (update). However, it lacks details on idempotency, side effects (e.g., whether unchanged fields are preserved), or error conditions. The description is moderately transparent but could be improved.

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, concise and front-loaded with the action ('Update one gi sponsor placement'). Every part adds value: the slot source, the fields, and the owner constraint. 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?

Given the tool has 5 parameters, no output schema, and no annotations, the description provides a sufficient high-level overview. It covers the action, data source (mu_gi_logos), and authorization. However, it omits the response format and potential errors. For a mutation tool with moderate complexity, it is mostly complete.

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

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

Schema description coverage is 100% with detailed parameter descriptions. The description adds modest value by summarizing the purpose of parameters ('swap its logo_url, set its status and/or add a note'), but this does not significantly enhance understanding beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool updates a gi sponsor placement by slot, referencing the sibling tool mu_gi_logos for slot enumeration, and lists specific fields (logo_url, status, note). It distinguishes itself from sibling tools (e.g., mu_gi_logos is for listing) by specifying 'update one' and '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 implicitly provides usage guidance by stating 'by slot from mu_gi_logos', indicating that users should first use mu_gi_logos to obtain slots. It also restricts usage with 'Owner-only'. However, it does not explicitly state when not to use this tool or mention alternatives for other actions (e.g., adding or deleting sponsors).

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, so description carries full burden. Clearly states it generates drafts but does NOT send, and is owner-only. Discloses human gate and follow-up action. No destructive behaviors mentioned.

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 action and conditions. 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 no parameters and no output schema, description covers all: purpose, eligibility, restrictions, non-sending, and next step (mu_gi_logo_set). Complete for 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?

No parameters in schema, so coverage is 100%. Baseline 3 applies; description adds no parameter information because none needed.

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

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

Description clearly states it drafts permission-request emails for gi sponsors whose consent is not yes. Distinguishes from sibling mu_gi_logo_set which records consent, and clarifies it does not send emails.

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?

Indicates use when consent is not yes, and that it's owner-only. Implicitly says when not to use (if consent yes). Does not provide explicit alternatives, but references mu_gi_logo_set for recording.

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 burden of disclosing behavior. It clearly indicates a read operation (returns URLs) and includes a critical access constraint ('owner-only'). It also notes the tech-pack PDF location, adding behavioral context. 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?

Two efficient sentences. The first sentence front-loads the core purpose (return URLs), the second adds supplementary info (PDF location, owner-only). No wasted words.

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

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

For a tool with no parameters and no output schema, the description covers return types, a key constraint, and related file location. It is sufficient for a simple tool, though it could specify the exact structure of returned URLs (list vs object) 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?

No input parameters exist (schema coverage 100% trivially). Baseline for 0 parameters is 4. The description adds output context (which URLs are returned) which aids understanding, but since there are no parameters, it cannot add parameter-specific 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 clearly states the tool returns URLs for the MU × JiuFlow gi's public page and mockup images (front, back, crest, QR). It uses a specific verb ('Return') and identifies the resource exactly. It distinguishes from siblings like mu_gi_logos by focusing on techpack/mockup assets.

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

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

The description mentions 'owner-only', indicating a permission constraint, but does not provide explicit guidance on when to use this tool versus alternatives like mu_gi_logos or mu_preview_mockup. No 'when not to use' statement is present.

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 needed authorization and returned fields, but no mention of pagination, order, or rate limits. With no annotations, description carries full burden but omits some 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 sentences—first lists output fields, second states auth requirement. No wasted words, front-loaded with 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 zero-parameter list tool with no output schema, description is mostly complete. Missing details: pagination, error handling, but adequate for typical 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?

No parameters in schema, so baseline is 3. Description adds value by listing all returned fields (sku, store, label, etc.), which goes beyond the empty 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?

Clear verb 'List' and specific resource 'every product you have created across your MU stores', differentiating from sibling tools like mu_create_product or mu_retire_product.

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 it lists the user's own products and requires authorization, but no explicit guidance on when not to use or alternatives for filtered queries.

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 key behaviors: no creation/charges, different rendering based on kind, durable image URL, optional position with WYSIWYG, polling for processing status. No annotations, so burden is fully on description. Does not cover error scenarios, but otherwise thorough.

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?

Well-structured with key point front-loaded. Slightly lengthy but each sentence adds value. Could trim minor redundancies (e.g., mentioning WYSIWYG twice). Still very 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 tool with 4 parameters, nested objects, one large enum, and no output schema, the description covers all essential aspects: two usage modes, polling, rate limits, authentication, and parameter interdependencies. Comprehensive without being overwhelming.

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 description adds significant value: explains the purpose of each parameter, clarifies mutually exclusive requirements (preview_id vs design_url+kind), and details the position parameter with the WYSIWYG guarantee.

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

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

The description clearly states the tool's purpose: 'See the mockup BEFORE creating any product — nothing is created or sold, and it costs no credits.' It specifies rendering behavior on real garments or MU product cards, and distinguishes itself from related tools like mu_create_product.

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

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

Provides explicit guidance on when to use (before creating) and what to do if status is 'processing'. Mentions rate limits and authentication. Could more directly state when not to use or compare to alternatives, but the sibling list includes mu_create_product, implying the alternative.

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

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

With no annotations, the description fully discloses behavior: read-only (creates nothing), no API key required, infers kind from description, ranks options, and explains output fields (supplier, price, MOQ, lead time, route, mode). This is comprehensive and leaves no ambiguity about side effects or prerequisites.

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 fairly long but information-dense. It front-loads the main purpose and then covers details. Every sentence adds value. Could potentially be broken into clearer sections, but overall it earns its length.

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

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

Given no output schema, the description thoroughly covers what the tool returns (supplier, price, MOQ, lead time, fulfillment route, mode) and explains ranking logic and follow-up actions. This is complete for a routing tool with 5 optional 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 coverage is 100% with descriptions for all 5 parameters. The description adds extra context, such as example strings for 'kind' and 'description', and explains how 'qty' checks MOQ, 'budget' flags within_budget, and 'region' prefers region-matching. This adds moderate 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's purpose: asking the MU manufacturing router how a thing could be made, providing details like supplier, estimated unit price, MOQ, lead time, and fulfillment route. It uses specific verbs ('Ask', 'how a thing could be MADE') and distinguishes from siblings by focusing on pre-creation quotation/routing.

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: 'before you create a product'. Provides clear follow-up guidance: if mode is 'auto', use mu_create_product; if 'quote', needs human RFQ. Also explains optional parameters and ranking logic, helping the agent decide when this tool is appropriate.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It transparently states that the tool emails a verification code and requires no auth. However, it does not mention potential side effects (e.g., what happens if the email is already registered, rate limits, or idempotency). The overall transparency is 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?

The description is extremely concise—two sentences that cover purpose, process, next step, and authentication requirement. Every sentence adds value with no redundancies. Structure is 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 no output schema, the description should ideally mention what the tool returns. It states that an email is sent but doesn't describe the API response (e.g., success message or error handling). While it covers the registration flow and follow-up, the lack of response specification leaves a gap. Adequate but not fully complete.

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

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

Schema description coverage is 100%, so the input schema already describes each parameter. The description reiterates that 'email' receives the code and notes 'agent_name' is optional, but adds no new semantic meaning beyond the schema. Thus, it meets the baseline of 3.

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

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

The description clearly states the tool's purpose: 'Start MU agent registration.' It specifies that it emails a verification code and distinguishes from the sibling tool mu_verify, which is the next step. The verb 'register' combined with resource 'MU agent' makes it distinct from other sibling tools like mu_create_product or mu_create_store.

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 the user to follow up with mu_verify after receiving the code, and notes that no authentication is required. Although it doesn't explicitly state when not to use this tool (e.g., for existing users), the context of registration implies it's for new users. It provides clear sequential guidance, earning a 4.

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 effectively communicates key behavioral traits: the tool sets status=retired, removes the product from the storefront, is owner-only, and requires an API key. It does not mention reversibility or side effects, but the core destructive action is well-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?

The description is extremely concise, using two sentences to convey purpose, effect, ownership requirement, and authentication. Every word 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?

For a simple tool with one parameter and no output schema, the description covers the core behavior, authorization, and ownership. It could be more complete by mentioning the return value or any irreversible consequences, but it is sufficient for the given complexity.

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

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

Schema coverage is 100% (one parameter 'sku' with a description in the schema). The main description does not add additional meaning about the parameter beyond what the schema already provides, so it meets the baseline of 3.

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

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

The description clearly states the verb 'Retire' and the resource 'your products', specifying that it sets status to retired and removes from storefront. This distinguishes it from sibling tools like mu_update_product or mu_create_product, which handle different operations on 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 explicitly notes 'Owner-only' and requires 'Authorization: Bearer <api_key>', indicating who can use it and under what auth conditions. However, it does not mention when not to use it 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, but the description discloses key behaviors: generates draft, saves as 'drafted', does not send, and mentions account scoping. It lacks details on potential side effects or error conditions, but is still transparent for a creation tool.

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

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

The description is a single focused paragraph that front-loads the critical 'does NOT send' and efficiently conveys all key points without unnecessary verbosity.

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 8 parameters and no output schema, the description covers the workflow, parameter relationships, and behavioral constraints well. It is sufficiently complete for an agent to use the tool correctly.

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

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

With 88% schema coverage, the description adds context beyond the schema, such as explaining the resolution logic for supplier_id vs kind/description and the purpose of optional params like spec_id from mu_spec_draft. This enhances understanding.

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 opens an RFQ draft to non-POD suppliers, distinguishing it from sibling tools like mu_rfq_list and mu_quote. It specifies the verb 'Open a quote request' and the resource 'RFQ draft', with specific supplier types.

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 that the tool does not send, only drafts, and is scoped to the user's account. It provides parameter guidance (supplier_id OR kind/description) but does not explicitly differentiate from mu_quote, 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?

With no annotations, the description carries the full burden. It discloses scoping behavior ('RFQs are scoped to your account; admin sees all') and lists available filters. However, it does not mention pagination, rate limits, side effects, or return format, leaving behavioral gaps.

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 remarkably concise: one sentence for the main action and another for scoping. Every word 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?

For a list tool with no output schema and low schema coverage, the description is underspecified. It omits details on pagination, sorting, output format, and parameter constraints. The scoping information helps but is insufficient for a complete understanding.

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 must explain parameters. It defines the 'status' enum values, which adds meaning. However, 'supplier_id' and 'kind' are described only by name, with no format, example, or default behavior, leaving ambiguity.

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 'quote requests (RFQs)', specifies optional filters, and scopes to the user's account. This differentiates it from sibling tools like mu_rfq_create (creation) and mu_list_mine (which likely lists other entities).

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 context for when to use this tool (listing RFQs with filters) and mentions optional filters. However, it does not explicitly exclude alternatives or give guidance on when not to use this tool compared to siblings like mu_rfq_record or mu_list_mine.

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 fully disclose behavior. It explains the required condition for status='received' and the side effect on mu_quote. However, it omits what happens when updating from received to another status or the effect of past valid_until dates.

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

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

The description is a single sentence that efficiently conveys the main action and parameter details. It could be slightly restructured for readability, but every part is essential.

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 main use case but lacks details on return values, error conditions, and behavior for edge cases (e.g., updating expired quotes). With no output schema, more completeness would be helpful.

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

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

The description adds meaning beyond the input schema by explaining the relationship between status and quoted_unit_jpy, the ISO date format for valid_until, and the side effect. Schema coverage is 57%, but the description compensates well.

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

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

The description clearly states the tool's purpose: recording a supplier's RFQ reply with specific fields. It distinguishes from siblings like mu_rfq_create and mu_rfq_list by focusing on the reply recording action.

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

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

The description indicates when to use (after factory replies) and explains the side effect on mu_quote. It also mentions account scoping. However, it does not explicitly state when not to use or compare with 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 present, the description carries the full burden. It discloses that the tool 'gets' data (implying read-only) and specifies the exact output fields. However, it does not mention any side effects, rate limits, or idempotency. The authentication requirement is stated, but more details on behavior (e.g., whether it returns historical data, pagination) are missing.

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

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

The description is extremely concise: two sentences that front-load the core functionality and follow with the authentication requirement. Every word is used efficiently 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?

Given no output schema and zero parameters, the description fully explains what the tool returns: per-store and total aggregate metrics plus the 50 most recent orders with specific fields. This is comprehensive for a simple read tool.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter information beyond what the empty schema provides, and it accurately reflects no inputs. No extra meaning is added, but none is 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 the tool retrieves sales for MU stores, specifying both per-store and total metrics (order_count, revenue_jpy) and the 50 most recent orders with field details. This distinguishes it from sibling tools like mu_list_mine (which likely lists something else) and mu_affiliate (which probably deals with affiliate data).

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 a required authentication header but provides no guidance on when to use this tool versus alternatives like mu_list_mine or mu_status. No exclusion criteria or context for selection 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 provided, the description carries the full burden. It discloses that the tool returns a specific structure (filename, csv_utf8, csv_shift_jis_base64) and explains which encoding to use for import. It also notes the owner-only restriction, which is a behavioral constraint. No contradictions with missing 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 reasonably concise, with the main action in the first sentence and additional critical details (output format, prerequisite) in subsequent sentences. It is front-loaded and each sentence contributes meaningful information. Slight redundancy with the title ('owner only') but overall effective.

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 (1 parameter, no output schema, no annotations), the description is fairly complete. It covers what the tool does, the output format, the prerequisite, and an authorization constraint. Missing details like the definition of 'un-shipped' are minor; overall it provides sufficient context 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?

The schema covers the parameter 'courier' with an enum and a brief description. The tool description adds value by explicitly naming the target systems (yamato=B2クラウド, sagawa=e飛伝) and implying the default, providing context beyond the schema. Since schema coverage is 100%, baseline is 3, but the added context justifies a 4.

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 generates a courier shipping-label CSV for un-shipped orders, specifying the verb 'generate' and the resource. It explicitly mentions two courier formats, which distinguishes it from sibling tools like mu_ship_orders that likely handle different shipping tasks. However, it does not explicitly differentiate from all 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?

The description provides clear context on when to use the tool: for all un-shipped orders when needing a CSV for Yamato or Sagawa pickup. It explains that no carrier API or contract is needed and mentions a prerequisite (register column layout), which guides the user. However, it does not state when not to use it or compare with 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 fully conveys the key behaviors: it imports tracking, matches IDs, sets tracking, and marks orders shipped in bulk. It does not mention rate limits or confirmation, but the bulk import action is clearly 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?

The description is just two sentences, each carrying essential information. It is front-loaded with the main action and wastes no 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?

Given no output schema, the description explains the output effect (sets tracking, marks shipped). It references a counterpart tool for completeness. Minor gap: no mention of error handling or duplicate handling.

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 both parameters, providing a baseline of 3. The description adds meaningful context beyond the schema: the CSV must come from a specific system after labeling and contains specific fields (お客様管理番号 and 送り状番号). The courier default is implied as yamato.

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

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

The description clearly states the tool's purpose: importing courier tracking numbers from a B2クラウド/e飛伝 label CSV. It explicitly says it matches MU-{id} to orders, sets tracking, and marks shipped in bulk. This distinguishes it from siblings like mu_ship_csv, which is mentioned as its 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?

The description specifies when to use the tool (after issuing labels from the specific system) and notes it is owner-only. It references mu_ship_csv as a natural counterpart, giving context but not explicit when-not-to-use or alternative 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?

With no annotations, the description discloses key behavioral traits: owner-only access, recording courier/tracking when shipping, and the notify option. It lacks details on reversibility or error handling, but the core behavior is clear.

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 the main action and constraints. Every word adds value; no filler.

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

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

Given 5 parameters and no output schema, the description covers the update behavior and key conditions. It doesn't explain return values or side effects beyond the notify option, but is adequate for the tool's simplicity.

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 minimal value beyond the schema, as it restates that courier/tracking apply when shipped (already in schema descriptions). Slight reinforcement but not significant.

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 ('Advance') and resource ('physical order's ship_status'), clearly distinguishing this tool from sibling tools like mu_ship_orders (listing) and mu_ship_order (creating).

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

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

The description states it's owner-only and lists valid statuses, providing clear usage context. However, it does not explicitly differentiate when to use this tool versus siblings like mu_ship_csv or mu_ship_import_tracking.

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 full burden. It discloses address/phone masking behavior, which is a key behavioral trait. But it does not explicitly state it is a read-only operation or mention other behaviors like rate limits or idempotency.

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 main action, and every part adds value. No redundant or vague language.

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

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

For a simple fetch tool with no output schema, the description adequately covers the returned fields (status, courier, tracking, address/phone) and the access restriction. Could be slightly improved by noting it's a GET request, but overall sufficient.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal context beyond the schema: it confirms 'id' is catalog_orders.id and describes the effect of 'reveal'. No additional syntactic or format details.

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

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

The description clearly states it fetches a single order with specific fields (status, courier, tracking) and explains the masking behavior. It distinguishes from sibling tools like mu_ship_orders by specifying 'single' and '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 implies usage for fetching a single order detail, and 'owner-only' restricts who can use it. However, it does not explicitly state when to use versus alternatives like mu_ship_orders, nor provide scenarios to avoid.

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

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

Despite no annotations, the description discloses key behaviors: it requires owner auth (403 otherwise), lists possible ship_status values, and explains PII masking with the reveal parameter. It does not explicitly state it's a read-only operation, but it's implied.

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

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

The description is two sentences long with no wasted words. It front-loads the core purpose and then provides essential details about authentication and parameters. 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?

Given no output schema, the description mentions returned fields (ship_status, courier, tracking). It covers authorization, parameter behavior, and purpose adequately. However, it could mention ordering or pagination if applicable, but for a simple list tool it is fairly complete.

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

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

The schema covers both parameters fully (100% coverage), and the description adds meaningful guidance: for 'all', it clarifies default false includes only active orders; for 'reveal', it explains the masking behavior and advises using true only when necessary. This adds 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 lists physical-shipping orders with specific fields like ship_status, courier, and tracking. It is distinct from sibling tools like mu_ship_csv and mu_ship_mark, but does not explicitly differentiate them, so it loses a point.

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 context on when to use reveal (only when needed) and notes owner-only authorization. However, it lacks explicit guidance on when not to use this tool compared to siblings, and no alternatives are mentioned.

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

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

Discloses that missing attributes return as 'missing' with a follow-up question, uses AI budget, and requires prior registration. No annotations provided, so description carries the burden and does so effectively.

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 compact description covering purpose, process, and requirements without unnecessary words. It is well-structured and 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 one parameter and no output schema, the description adequately explains the input format, missing attribute behavior, and the next step. Could mention return format but is generally 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 has 100% coverage for the single parameter, but the description adds context with an example and explains how missing attributes are handled, adding 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's function: converting natural language into a structured manufacturing spec. It specifies the fields included (kind, material, etc.) and distinguishes from sibling tools like mu_rfq_create by focusing on draft 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 says to feed the spec_id into mu_rfq_create and mentions API key requirements. Provides clear next steps, though does not explicitly state when not to use this 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 description must fully disclose behavior. It states it's a read operation returning specific fields and requires auth, but does not detail rate limits, idempotency, or error handling.

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 efficient sentences: first sentence front-loads the core purpose and fields, second adds authentication requirement. 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 parameterless tool without an output schema, the description adequately covers purpose and auth. Could mention possible errors or rate limits, but overall sufficient.

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, so baseline is 4. The description adds value by listing the returned fields, enriching the agent's understanding 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 retrieves the authenticated agent's profile including specific fields like email, credits, flag, stores, and limits. This distinguishes it from sibling tools that perform 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?

The description mentions authentication requirement but does not explicitly state when to use this tool over siblings or provide alternative tools. The context implies it's for checking current user status.

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 authentication requirement ('Requires Authorization: Bearer <api_key>') and that feedback lands in a triage queue. 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?

Three sentences: purpose, usage scenario, auth requirement. Front-loaded, no fluff.

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

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

Covers purpose, usage, auth, and queue destination. No output schema, but for a feedback submission this is adequate. Could mention expected response (e.g., confirmation).

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 value by explaining category enum values (bug/feature/improvement), max lengths, and optional fields beyond 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?

Description starts with 'Report a bug or suggest an improvement to MU' – a specific verb+resource purpose. It clearly distinguishes from sibling tools focused on products, stores, and 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?

States when to use: platform/API misbehaves, product looks wrong, feature request. Lacks explicit when-not-to-use or alternatives, but context is clear and no sibling overlap.

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?

Since no annotations are provided, the description carries full burden. It discloses allowed states, mutable fields, price clamping, mockup re-rendering, immutable properties, and owner-only restrictions. This is thorough.

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 paragraph that is concise and front-loaded with the purpose and key constraint. It efficiently lists changable fields with brief notes. Slightly more structure (e.g., bullets) could improve readability but still effective.

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 complexity (6 params, nested object, no output schema), the description covers constraints, per-field behavior, preview suggestion, and auth. It does not describe return values, but that is acceptable without an output schema. Fairly 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 baseline is 3. The description adds value by explaining price clamping, position constraints (front-print DTG only), and preview recommendation. It clarifies parameter semantics beyond 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 updates a product, specifies allowed product states ('review' or 'retired'), and lists mutable fields. It distinguishes itself from siblings like mu_create_product and mu_retire_product.

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

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

The description explicitly says updates are only for non-live products and includes constraints like 'Printful ids can never change' and auth requirements. It could be more explicit about when to use alternatives, 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?

Describes input format, size limit, output (durable URL), and auth header. Lacks mention of error handling for invalid inputs, but covers core behavior well.

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, every word is necessary and informative. No fluff.

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

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

For a simple upload tool with 2 parameters and no output schema, the description fully covers input, output, auth, and integration with sibling 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 already covers both parameters thoroughly; description adds workflow context (base64 encoding, size limit, and how to use the URL) that enhances understanding.

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 uploads a PNG design (base64) and returns a durable URL, which is distinct from siblings like mu_create_product that consume the URL.

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 explains when to use (uploading design image) and the follow-up action (pass URL to mu_create_product), plus authentication requirement.

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 full burden. It discloses that the call returns a permanent api_key, how to use it in subsequent calls, and that no authentication is required. This provides essential 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 concise sentences that front-load the purpose and key usage details. 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?

Despite lacking an output schema, the description explains the api_key return and its usage. It addresses the authentication context. Minor omission of error handling (e.g., invalid code) but sufficient for a simple verification 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 descriptions for both parameters. The description adds that the code is 6-digit and originated from mu_register, but this largely duplicates the schema's parameter descriptions. No significant new semantics added.

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 a permanent api_key. It distinguishes itself from the sibling mu_register by specifying the verification step after registration.

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 the tool is used after mu_register and before other MU tools, and that no authentication is needed for this call. However, it does not explicitly mention when not to use it or 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.