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?

With no annotations provided, the description carries full burden and excels. It discloses that products go live immediately for trusted owners unless risk gate trips, then wait for MA-council review. It explains AI generation costs mu_credits, phone_case behavior, and the need to always check 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 well-structured. It front-loads the main purpose, then systematically covers artwork options, kind enumeration, special digital kinds, and go-live behavior. While not extremely concise, every sentence adds value given the complexity of the tool.

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

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

For a complex tool with 12 parameters and many product kinds, the description is remarkably complete. It covers all special cases, references companion tools (mu_preview_mockup, mu_status), and addresses authorization and response handling. No output schema exists, but the description adequately explains what to expect from the response (status field).

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?

Though schema description coverage is 100%, the description adds critical context beyond the schema: for kind it clarifies digital vs physical and extra fields; for phone_case it explains iPhone model selection; for position it mentions previewing with mu_preview_mockup; for ai_prompt it links to mu_status for cost info. This adds significant 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 'Create a product in one of your MU stores,' specifying the exact verb and resource. It distinguishes from sibling tools like mu_update_product and mu_retire_product by focusing on creation. The alternative artwork methods (design_url vs ai_prompt) further clarify the tool's scope.

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

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

The description provides explicit when-to-use guidance: 'Provide the artwork EITHER as design_url OR as ai_prompt... Pass exactly one of the two.' It details special cases for digital kinds (event_ticket, song) and notes the Authorization header requirement. It also warns about the risk gate and advises always reporting the status field.

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?

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?

No annotations provided, so description carries full burden. It discloses key behaviors: no creation, no credit cost, durable URL, optional position constraints, processing state, polling, rate limit (30/hour), and auth requirement. 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?

Description is informative but slightly long; however, it is front-loaded with the most important info and every sentence adds value. Could be trimmed slightly but remains 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?

Complex tool with nested objects, polling, and rate limits. Description covers all major aspects, though no output schema is provided. Mentioning return format explicitly (e.g., response shape) would improve completeness, but current description is adequate.

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

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

Schema coverage is 100%, but description adds significant meaning: explains position is for front-print DTG apparel only, specifies which product kinds support it, notes WYSIWYG behavior, and clarifies preview_id for polling. Enriches understanding 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 tool's purpose: to preview a product mockup before creating. It uses specific verb 'see' and resource 'mockup', and contrasts with sibling tools like mu_create_product and mu_upload_design by emphasizing 'BEFORE creating any product' and noting that nothing is created or sold.

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, for both Printful and card sources. Explains the position parameter for custom placement and WYSIWYG behavior relative to mu_create_product. Instructs on polling with preview_id when status is 'processing'. Includes rate limit and auth requirements.

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?

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?

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.