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

No annotations provided, so description carries full burden. It only states 'Create' but does not disclose behavioral traits like permissions, idempotency, error handling, or rate limits.

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 well-organized with bullet points and a code block example. Each line adds value; no unnecessary content.

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

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

Given the presence of an output schema (not shown), the description adequately covers input. However, it lacks details on error cases, validation rules, or constraints (e.g., duplicate attributes).

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

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

Input schema only defines 'data' as a string with 0% schema coverage. Description adds detailed structure (JSON array of attribute objects with name, type, values) and a clear example, significantly compensating for the schema gap.

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

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

The description clearly states 'Create one or more product attributes' with a specific verb and resource. It distinguishes itself from sibling tools like attribute_list and attribute_update.

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

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

No explicit guidance on when to use this tool vs alternatives. Does not mention prerequisites, idempotency, or that attribute_list should be used first to check for existing attributes.

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 disclose behavior. It only mentions parameters and basic output (list), but does not clarify read-only nature, auth requirements, or pagination behavior (though page/limit parameters imply pagination). Missing details like whether id returns a single attribute or a list with one element.

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

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

Extremely concise with a clear header and bullet-like parameter list. No unnecessary words or repetition. 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?

Adequate for a simple list tool with no required parameters and an output schema. However, it lacks details on return format, default pagination, and authentication requirements. Could be more 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 0%, so description adds value by explaining each parameter: id for filtering, page for pagination, limit for items per page (with range 1-100). This goes beyond schema which only has titles and types.

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 'List product attributes defined in the store.' It uses a specific verb ('list') and resource ('product attributes'), making the purpose unambiguous and distinguishing it from sibling tools like attribute_create or attribute_update.

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

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

No guidance on when to use this tool versus alternatives, no preconditions, exclusions, or when-not-to-use instructions provided. The description only states what it does.

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 states 'patch' semantics, implying non-destructive partial updates, but does not disclose permissions, side effects, or whether changes are reversible.

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

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

The description is concise: a one-line purpose, parameter explanation, and example. No wasted sentences, front-loaded with the key 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 the simple tool (one parameter, output schema exists), the description covers the purpose, parameter format, and example. It does not explain return values, but the output schema presumably fills that gap.

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

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

The schema only defines 'data' as a string with 0% coverage. The description explains it must be a JSON array of partial attribute objects with 'id' and provides a concrete example, adding essential structure and constraints.

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

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

The description clearly states 'Update (patch) existing product attributes,' which specifies the verb (update/patch) and resource (product attributes). It is distinct from sibling tools like attribute_create and attribute_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 implies use when updating attributes but provides no explicit guidance on when to use this vs alternatives like attribute_create. No when-not conditions or exclusions 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?

No annotations provided, so the description carries full burden. It indicates a read-only operation ('Return the list') but does not disclose authentication requirements, rate limits, or whether the list is complete or filtered. Adequate but minimal.

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

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

Single sentence, 12 words, front-loaded with the key verb and resource. No unnecessary information, every word earns its place.

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

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

Given the tool has zero parameters and an output schema exists (though not shown), the description fully specifies the tool's purpose. It is complete for a simple retrieval list tool with no 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?

No parameters exist, so schema coverage is 100%. The description adds no parameter details, but baseline for 0 parameters is 4. No need to compensate for missing schema information.

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

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

The description clearly states the action ('Return') and the resource ('list of configured shipping carriers/couriers available in the store'), which distinguishes it from sibling tools like awb_list or awb_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?

No explicit guidance on when or when not to use the tool, nor mention of alternatives. However, the tool's simplicity and uniqueness among siblings make usage intuitive, but lacking contextual comparison.

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 that this is a manual creation, lists parameter fields with types, and provides an example. However, it does not mention auth requirements, error handling, or what happens on duplicate AWB numbers.

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: a single sentence for purpose, then a structured list of parameters with types and descriptions, followed by a clear example. Every sentence adds value with no repetition.

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

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

The tool has an output schema (not shown), so return values are covered. The description provides enough detail to call the tool correctly, including required fields from awb_carrier_list(). Minor gap: does not mention validation or error responses, but for a simple creation tool 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?

The input schema only defines 'data' as a string with no description (0% coverage). The description compensates fully by listing key fields (orderId, carrierId, awbNumber, packages, weight) with types and brief descriptions, plus a concrete example. This adds significant meaning 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 explicitly states 'Manually create an AWB record for an order', using a specific verb and resource. It distinguishes from siblings like awb_generate (auto-generate) and awb_print (print) by emphasizing manual 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 implies usage context by referencing awb_carrier_list() for the carrierId parameter, but does not explicitly state when to use this tool versus alternatives or provide exclusions. It is clear enough for straightforward creation.

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 only states 'Delete,' implying a destructive action but does not warn of irreversibility, required permissions, or potential cascading effects (e.g., data loss).

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, with a single sentence and a parameter definition. It is front-loaded with the action, and every element serves a purpose. However, it could be structured to include a warning or more context in the same space.

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

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

For a simple delete tool with one parameter and an output schema, the description minimally suffices. Yet it omits any mention of success/error responses, idempotency, or side effects. Given the lack of annotations, more completeness would aid agent decision-making.

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 has 0% description coverage, so the description is the sole source of parameter meaning. It defines 'awb_id' as 'Internal AWB record ID,' adding crucial context beyond the schema's title and type. This compensates adequately for the schema gap.

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

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

The description explicitly states 'Delete an AWB record,' which clearly indicates the verb (delete) and resource (AWB record). This distinguishes it from sibling tools like awb_create, awb_list, or awb_update_status, though it could be more specific about the scope (e.g., by ID).

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

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

The description provides no guidance on when to use this tool versus alternatives, such as awb_update_status or awb_generate. It lacks prerequisites, exclusions, or context about when deletion 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, the description only states it generates an AWB automatically, but does not disclose side effects, permissions, idempotency, or state changes.

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

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

The description is concise with a clear header and structured parameters section, including an example. No wasted words, and front-loaded with the 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?

Given the existence of an output schema, the description does not need to explain return values. It covers input structure well but lacks info on error handling or prerequisites.

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 has 0% coverage for the single string parameter 'data', but the description compensates by detailing the expected JSON structure with key fields and an example, adding 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 'Generate an AWB automatically through the carrier's integrated API,' using a specific verb and resource. It distinguishes from sibling 'awb_create' by implying automated integration.

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 an example and references 'awb_carrier_list()' for carrierId, but does not explicitly state when to use this tool versus alternatives like 'awb_create' or when not to use it.

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

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

No annotations provided, so description should disclose behavioral traits. It only says 'List,' which implies read-only, but does not explicitly state safety or lack of side effects. No mention of pagination behavior, limits, or data freshness.

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 concise and structured with a header and parameter list. Each sentence serves a purpose, though the parameter descriptions could be slightly consolidated.

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

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

Given a simple list tool with 5 parameters and an output schema, the description covers the necessary input semantics. Lacks details on error handling or pagination behavior, but output schema may compensate for return value documentation.

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

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

Schema description coverage is 0%, so description must compensate. It provides clear one-line explanations for all 5 parameters (order_id, awb_number, carrier_id, page, limit), adding meaning beyond the schema's type and default.

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 'List AWB records' with a specific verb and resource. It distinguishes from sibling tools like awb_create, awb_delete, etc., which are clearly different operations.

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

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

No guidance on when to use this tool versus alternatives. No mention of scenarios where a different AWB tool would be preferable, e.g., awb_generate for creating new AWBs.

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 responsibility. It mentions the return type (URL or base64) but does not disclose whether the operation has side effects, requires authentication, or has rate limits. The behavior is minimally 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 with two sentences plus a parameter definition. Every part is necessary and there is no 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?

The description covers the return format (URL/base64) and one parameter. However, given the presence of an output schema, more context on the return structure could be inferred, but behavioral details (e.g., any state changes) are missing. Adequate for a simple print tool but not fully comprehensive.

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

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

The input schema has no parameter descriptions (0% coverage), but the tool description explicitly defines 'awb_id' as 'Internal AWB record ID.', adding meaning beyond the raw schema. This helps the agent understand the parameter's role.

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

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

The description clearly states the action ('generate'), resource ('printable shipping label'), and scope ('for an AWB'). It distinguishes from sibling tools like awb_create, awb_list, etc., though not explicitly from awb_generate. Overall, purpose is unambiguous.

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

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

No guidance on when to use this tool vs alternatives is provided. Siblings include awb_generate which might be similar, but no differentiation or context is given. The description does not specify prerequisites or use cases.

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?

Without annotations, the description discloses the mutation behavior ('update') and a key side effect: if update_order_status is true, it also updates the parent order status. This adds context beyond the basic update action. However, it does not discuss error handling or whether the AWB must exist.

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

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

The description is concise: a one-line summary followed by a parameter list in docstring format. No unnecessary text; every sentence provides 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 three parameters, no annotations, and an output schema likely covering return values, the description covers the parameters and the side effect of update_order_status. It could mention prerequisites (e.g., AWB must exist) but is otherwise sufficient for a mutation 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 description coverage is 0%, so the description fully compensates. It explains awb_id as 'Internal AWB record ID', status as a carrier-specific string with examples, and update_order_status's effect. This adds meaning that the schema (with only titles) lacks.

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

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

The description clearly states 'Update the delivery status of an AWB.' This distinguishes it from siblings like awb_delete (delete AWB) and order_update_status (update order status). The verb 'update' and resource 'delivery status of an AWB' are specific and unambiguous.

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

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

The description does not explicitly state when to use this tool versus alternatives like order_update_status. Usage is implied by the tool's name and parameter descriptions, but no 'when not to use' or alternative tools are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Return banners,' implying a read-only operation, but does not mention any behavioral traits such as pagination behavior, authentication requirements, or whether the tool returns all banners or only filtered ones.

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: two sentences plus a structured parameter list. It front-loads the purpose and uses a clear format, with no unnecessary information.

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

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

Given the tool's simplicity (listing banners with optional filters) and the presence of an output schema, the description adequately covers the basics. However, it could provide more context about positions (e.g., how to discover them) or pagination defaults.

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

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

Schema description coverage is 0%, so the description compensates by explaining each parameter: position (filter by zone), page (page number), limit (results per page). However, it does not provide details like valid values for position or default pages/limits, making the explanation basic but functional.

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

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

The description states 'Return banners (promotional images/links) defined in the store.' This provides a specific verb and resource, distinguishing it from sibling tools like 'attribute_list' or 'brand_list', though it does not explicitly differentiate itself from other list tools.

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

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

No guidance is given on when to use this tool versus alternatives. The description only explains what the tool does without any context for when it should be chosen over other 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 must fully disclose behavior. It only says 'return the list' but does not explicitly state that it is read-only or has no side effects. While 'list' implies read-only, the lack of explicit statement is a gap for behavioral transparency.

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

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

The description is extremely concise: one sentence and a parameter list with no extraneous information. Every word earns its place.

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

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

Given that there is an output schema, the description need not explain return values. For a simple list retrieval, the description covers the basics but lacks information on pagination behavior, ordering, or authentication. It is adequate but not comprehensive.

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

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

Schema description coverage is 0%, so the description must add meaning. It provides minimal descriptions: 'Page number' and 'Results per page (1–100).' The range for limit is useful, but overall the added value is low, especially given the schema already has titles. More detail would be needed for a higher score.

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

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

The description clearly states it returns a list of brands/manufacturers, which is specific and distinguishable from sibling tools like product_list or category_list. However, it does not explicitly differentiate itself from other list tools, making it slightly less than perfect.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. This is a significant gap for an AI agent choosing among many sibling list tools.

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

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

No annotations are present, so the description carries the full burden. It does not disclose side effects, authorization requirements, rate limits, or idempotency. It only states the creation action without behavioral context.

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

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

The description is well-structured with a clear purpose statement, a list of parameters, and an example. It is not overly verbose, though it 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 an output schema exists (not shown), return values need not be explained. However, the description is missing usage guidelines and behavioral details. It adequately covers input but lacks completeness for a creation 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 has 0% description coverage, but the description thoroughly explains the 'data' parameter: it is a JSON array of category objects with fields (name, description, parent_id, enabled, image), types, and an example. This adds significant value.

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

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

The description states 'Create one or more categories,' clearly specifying the verb (create) and resource (categories). This distinguishes it from sibling tools like category_delete and category_update.

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

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

No guidance is provided on when to use this tool vs alternatives. Siblings include category_update and category_delete, but the description does not clarify when creation is appropriate or any prerequisites.

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

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

No annotations provided, so the description must carry the full burden. It discloses the deletion constraint and provides an example input format but omits other behavioral details such as irreversibility, required permissions, or potential side effects. This is adequate but not comprehensive.

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

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

The description is concise, starting with the core purpose, followed by constraints, parameter details, and an example. Every sentence adds value with no 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 that an output schema exists, the description does not need to explain return values. It covers the tool's purpose, the emptiness constraint, and parameter format. However, it could include information about error scenarios (e.g., what happens if the category is not empty) to be 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?

The input schema defines 'data' as a plain string with no description, so the description adds critical meaning: it specifies the expected JSON format (array of objects with 'id' fields) and provides an example. This fully compensates for the 0% schema description coverage.

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

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

Clearly states the verb 'delete' and resource 'categories', and immediately adds the crucial constraint that only empty categories can be deleted. This distinguishes it from sibling tools like category_create or category_update.

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 provides the condition for use ('only empty categories can be deleted'), guiding the agent to verify emptiness before invocation. However, it does not mention alternatives for non-empty categories or error handling, leaving some room for improvement.

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

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

No annotations are provided, so the description carries the burden. It describes a list operation, implying no side effects, but does not explicitly confirm read-only behavior or mention any constraints like rate limits or data freshness.

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

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

The description is concise and uses a readable parameter list format. It could be slightly more structured (e.g., bullet points), but it is efficient and front-loaded.

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

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

Given the existence of an output schema, the description adequately covers input parameters. It does not discuss return format or pagination defaults, but these are not essential for a simple list tool with an output schema.

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

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

The description explains each parameter (id, parent_id, view, page, limit) with clear semantics, adding meaning beyond the schema which has no property descriptions. With 0% schema description coverage, the description effectively compensates.

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

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

The description clearly states 'List product categories', which is a specific verb and resource. It distinguishes from sibling tools like category_create, category_delete, and category_update.

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

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

The description implies usage for listing categories but does not explicitly state when to use this tool versus alternatives (e.g., when to filter vs. list all). No when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description must carry the full burden. It mentions the tool is a patch operation and gives input format details, but fails to disclose side effects, authorization needs, rate limits, or error handling 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 concise with a clear purpose statement and structured parameter documentation. The example is helpful, but the parameter section slightly repeats the purpose. Overall, it is appropriately sized and front-loaded.

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

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

With an output schema present, the description doesn't need to explain return values. However, it lacks any mention of constraints, validation rules, or expected behavior for missing IDs. For a simple one-parameter update tool, it is adequate but not fully comprehensive.

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 has 0% description coverage, so the description compensates well by explaining that 'data' is a JSON array of partial category objects requiring an 'id' and fields to change, plus an example. This adds significant meaning beyond the schema's bare string type.

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

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

The description clearly states 'Update (patch) existing categories.' using specific verb 'update' and resource 'categories', distinguishing it from sibling tools like category_create, category_delete, and category_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 implies when to use (when updating categories) but provides no explicit guidance on when not to use or alternatives. No comparison with sibling tools is given, so usage context is minimal.

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, but the description implies a read-only operation by stating 'return the list'. This is sufficient for a simple list tool. The description does not contradict any annotations.

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

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

The description is a single, focused sentence that conveys exactly what the tool does with no extraneous information. 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?

For a simple list tool with no parameters and an output schema present, the description is complete. It explains the purpose sufficiently without needing to describe return values.

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 input schema provides no information. The description does not need to add parameter details. According to guidelines, baseline for 0 parameters is 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 verb 'return', the resource 'list of currencies', and the scope 'configured in the Gomag store'. It is specific and distinguishes this tool from any sibling tools, none of which relate to currencies.

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 is clear about what the tool does, but does not explicitly mention when to use it versus alternatives. However, since there are no sibling tools for currencies, this lack of explicit guidance is not a significant gap.

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 exist, so description carries the full burden. It notes passwords are plain text but never logged, and confirm_new_password must match. However, it lacks disclosure of success/failure behavior, side effects (e.g., notification), or security implications beyond logging.

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

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

The description is concise with a clear structure: a one-line purpose followed by a parameter list. Every sentence adds value. No redundant information.

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

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

Output schema exists, so return values need not be explained. The description covers parameter semantics and security notes. Missing prerequisites (e.g., customer must exist) and validation rules (e.g., password strength). Adequate but could be more 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 0%, so the description compensates by explaining each parameter: email, old_password with 'never logged', new_password with 'never logged', confirm_new_password with 'must match'. This adds significant meaning beyond the bare 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 'Change a customer's password.' with a specific verb and resource. It distinguishes from siblings like customer_password_recovery and customer_update by focusing on direct password change with old password verification.

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

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

The description implies when to use (customer wants to change password knowing current password) but does not explicitly state when not to use or mention alternatives like customer_password_recovery for forgotten passwords. The agent may need more guidance.

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

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

No annotations provided. The description adds important behavioral context: password security warning (plain text, use HTTPS, never logged) and email uniqueness constraint. This goes beyond mere parameter listing.

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 well-structured as a parameter list, but includes a 'Parameters' header that adds minor verbosity. Each line is meaningful and free of 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?

With 7 parameters (5 required) and an output schema present, the description covers all parameters with useful context and security notes. It does not describe return values, but the output schema likely handles that. Could benefit from noting idempotency or uniqueness enforcement.

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

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

Schema description coverage is 0%, but the description defines each parameter with relevant semantics: email (unique), password (security note), confirm_password (must match), phone (optional), newsletter (true/false). This adds significant meaning beyond the schema's type-only 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 'Create a new customer account' with a specific verb and resource. Among sibling tools like customer_list, customer_update, etc., this tool's purpose is distinct and unambiguous.

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

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

The description implies usage when a new customer is needed but does not explicitly state when to use versus alternatives, nor does it mention prerequisites, duplicate handling, or when not to use.

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

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

Discloses that the account is flagged for deletion and not immediately removed, but with no annotations, additional behavioral details (e.g., reversibility, email notifications) 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?

Concisely conveys purpose, effect, and parameter info in a few sentences. No unnecessary words; important points front-loaded.

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

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

Explains the main effect and mentions output schema existence (context signal). Lacks prerequisites or error scenarios, but acceptable 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?

Only one parameter 'email' with a clear description in the text ('Customer e-mail address'). Schema coverage is 0%, so description compensates fully.

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 submits a GDPR account-deletion request for a customer. Highlights that it does not immediately delete, distinguishing it from a hypothetical instant deletion tool.

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

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

Explicitly notes GDPR context and that the deletion is not immediate, guiding agents to use this for non-immediate requests. However, lacks explicit comparison to sibling tools or mention of when not to use.

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

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

No annotations are provided, and the description does not disclose safety traits (e.g., read-only nature), auth requirements, or pagination behavior beyond the parameter list.

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 brief, front-loaded, and structured as a clear list with no wasted words or redundant information.

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

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

The description covers all parameters and basic purpose, but lacks guidance on pagination, edge cases, and behavioral context, making it adequate but not fully comprehensive.

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 explicitly lists each parameter with a concise purpose (e.g., 'Filter by internal customer ID'), fully compensating for the 0% schema description coverage.

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

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

The description clearly states 'List customers registered in the Gomag store,' providing a specific verb and resource that distinguishes it from sibling tools like customer_create or customer_update.

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

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

No guidance is given on when to use this tool versus alternatives (e.g., customer_ordered_products for filtered lists) or any prerequisites for usage.

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 plain-text password and HTTPS requirement; no annotations provided so description carries full burden.

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 header, list, and return note; 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?

Simple tool, output schema exists, description covers key behavioral aspects sufficiently.

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 0%, but description adds meaning for both parameters (email, password) with security note.

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 'Authenticate' and resource 'customer', distinct from sibling tools like create or change password.

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

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

Implied use for login, but no explicit when-not or alternatives 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?

No annotations provided; description indicates read operation and pagination, but does not mention sorting, default limits, or response structure. Output schema exists, lessening burden, but more transparency on behavior is needed.

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

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

Description is very concise: one-line purpose followed by a clear parameter list. Front-loaded and no wasted sentences.

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

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

Given existence of output schema, description covers essential aspects: purpose, identification alternatives, pagination. Lacks details on possible errors or defaults, but adequate for its 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 0%, so description adds minimal but helpful semantics: 'Internal customer ID', 'alternative to customer_id', 'Page number', 'Results per page'. Could include format or constraints.

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

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

Description clearly states 'Get a list of products that a specific customer has ordered', which is specific and distinguishes from generic product_list. However, no explicit differentiation from sibling order-related tools like order_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?

Description implies alternatives for customer identification (customer_id vs email) and pagination parameters, but does not provide context for when to use this tool versus other tools like order_list or product_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 exist, so the description must carry full behavioral transparency. It only mentions that an email is triggered, but lacks details on side effects, authorization needs, rate limits, or response behavior. For a tool that sends an email, more context is expected.

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 (one sentence + parameter list) and front-loaded with the purpose. However, it could benefit from structured formatting or bullet points for clarity, though it remains 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?

The tool is simple (1 parameter) and has an output schema (not shown), so the description doesn't need to explain return values. However, it lacks usage guidelines and behavioral transparency, making it incomplete for an agent to fully understand how and when to use it.

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

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

The schema has 0% description coverage for the 'email' parameter. The description adds 'Customer e-mail address to send the recovery link to,' providing meaningful context beyond the schema's type-only definition. This compensates well for the lack of schema descriptions.

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

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

The description clearly states the action ('Trigger a password recovery e-mail') and the target resource ('a customer'). It is specific and distinguishes from sibling tools like 'customer_change_password' and 'customer_login'.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or context for usage. The description only states what it does, not when to use it.

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

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

No annotations exist, so the description must cover behavioral traits. It only states it updates details and gives an example, but fails to disclose side effects, permission requirements, reversibility, or update semantics (e.g., partial vs full replacement). This leaves significant 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 concise (two sentences plus an example) and well-structured. Every sentence is informative with no fluff, though the parameter details could be integrated more naturally.

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 input semantics are well covered, and an output schema exists (reducing need to describe return values). However, for a mutation tool, missing context like idempotency, error behavior, or required permissions makes it less than 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 single parameter 'data' is described as a JSON object requiring 'id' or 'email' plus fields to change, with an example. This adds substantial meaning beyond the schema, which only defines it as a string. Schema coverage is 0%, so 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 'Update an existing customer's details', which is a specific verb and resource. It distinguishes itself from sibling tools like customer_create, customer_list, and customer_delete_request, making selection unambiguous.

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

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

The description provides no guidance on when to use this tool over alternatives, nor does it mention when not to use it or any prerequisites. Such usage context is absent.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as read-only nature (despite the name implying it), authentication needs, or side effects. The parameter descriptions are minimal.

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

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

The description is concise with a clear structure, including a title and parameter list. Every sentence adds value, but it could be more efficient by integrating the parameter descriptions into the main text.

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 annotations and 0% schema coverage, the description is incomplete. It fails to explain how to handle the two optional parameters, and lacks any behavioral or safety context for a read operation.

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

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

Schema description coverage is 0%, so the description partially compensates by stating 'Customer's internal ID' and 'Customer e-mail (alternative identifier)'. However, it does not clarify if at least one is required or if they can be used together.

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 'Retrieve' and the resource 'customer's fidelity points balance'. It distinguishes from siblings as there is no other fidelity-related tool among the 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?

No guidance is provided on when to use this tool versus alternatives, or when not to use it. The description only states what it does without any usage context or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It implies a read operation ('Return'), but does not explicitly state it is read-only, nor does it disclose any behavioral traits such as authentication requirements, rate limits, or side effects. This is adequate for a simple retrieval tool but lacks depth.

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

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

The description is concise, starting with a clear one-sentence purpose, followed by a parameter list. It avoids unnecessary detail, but the parameter explanations are embedded in a docstring-style format that could be more structured. Still, it is efficient.

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

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

Given the tool has an output schema (not shown), the description does not need to explain return values. It covers both parameters adequately. For a simple retrieval tool with only 2 parameters, the description is sufficiently complete for an agent to invoke it correctly.

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

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

With 0% schema description coverage, the description effectively explains both parameters: category_id is a required Category ID, and view is a language code with examples. This adds meaningful context beyond the schema's titles and types, helping the agent understand the format and purpose.

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: 'Return the filterable attributes for a specific category.' It specifies a specific verb and resource, and given the sibling tools (e.g., attribute_list, category_list), this tool is distinct in returning filterable attributes for a category, not general category or attribute lists.

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

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

No guidance is provided on when to use this tool vs alternatives. The description only lists parameters without any context about typical use cases, prerequisites, or comparison to sibling tools like attribute_list or category_list. The agent receives no hints about 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, the description bears full burden for behavioral disclosure. It states cancellation but omits side effects (e.g., reversibility, impact on related data, permissions needed). This is insufficient for a mutation 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 very short and front-loaded, but it includes redundant formatting (e.g., 'Parameters' section that repeats the schema). It could be more concise or reorganized to front-load key behavior. Still, no wasted sentences.

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

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

Despite having an output schema and simple parameters, the description lacks essential context for a mutation tool—such as prerequisites (e.g., invoice must exist), idempotency, or success/failure signals. The agent would need to infer too much.

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

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

Schema description coverage is 0%, yet the description merely restates the parameter name ('Invoice ID to cancel') without adding type constraints, formatting, or context beyond the schema. It fails to compensate for the low coverage.

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

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

The description clearly states the tool's action ('Cancel (void) an invoice') with a specific verb and resource, and it is distinct from sibling tools like invoice_create or invoice_generate. However, it lacks nuance about what voiding entails.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., invoice_create or invoice_update_status). There are no exclusions or prerequisites noted, leaving the agent to infer 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?

Without annotations, the description must disclose behavioral traits. It indicates a write operation ('create') but does not mention side effects (e.g., order status changes), required permissions, idempotency, or error handling. The example shows a successful call, but no failure scenarios are 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 structured with a clear first sentence, a Parameters section, and an example. It is not overly long, but the parameter details could be more concise if embedded inline. The example is helpful.

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 creating an invoice with a complex JSON parameter, the description covers the main fields. However, it does not describe the return value (despite an output schema existing) and lacks details on prerequisites (e.g., order must exist). The absence of behavioral transparency also detracts from 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?

The input schema has 0% coverage, so the description compensates by listing key fields (orderId, number, date, series, dueDate) and providing an example. This adds significant meaning beyond the bare schema, though not all possible fields or exact formatting rules are detailed.

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 (register) an invoice for an order.' It uses a specific verb ('create') and resource ('invoice for an order'), distinguishing it from siblings like 'invoice_cancel' and 'invoice_generate'.

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

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools include invoice_cancel and invoice_generate, but the description does not explain when to register vs. generate vs. cancel an invoice.

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 present, and the description does not disclose side effects, permissions, or output details beyond auto-generation. The agent lacks information about what changes occur (e.g., order updates, email triggers).

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

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

The description is concise and well-structured, with a separate parameters section that adds value without redundancy. Every sentence serves a purpose, though the parameters section could be integrated into the prose.

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

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

The description covers the basic purpose and parameters but lacks details on output, prerequisites, or error conditions. Given the simplicity of the tool (2 parameters, output schema present), it meets minimum viability but could be more 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 description adds meaning to both parameters: order_id is defined as an internal order ID, and series is clarified as optional with a default behavior. This compensates for the 0% schema description coverage.

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

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

The description clearly states the tool auto-generates an invoice for an order using store settings, providing a specific verb and resource. However, it does not explicitly differentiate from sibling tools like invoice_create, which could be used for manual invoice generation.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites (e.g., order status requirements). Sibling tools like invoice_create or invoice_cancel exist, but the description gives no usage context.

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

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

No annotations are provided, so the description carries the full burden. It states the action but does not disclose side effects, authorization requirements, error conditions, or behavior when the file URL is invalid or inaccessible.

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

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

The description is concise (about 40 words) and well-structured with a parameters list. However, it repeats parameter names that are already in the schema; slightly redundant but not excessive.

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 that an output schema exists (context signal), the description does not need to explain return values. However, it lacks information about error handling, file size limits, idempotency, or what 'attach' means for the order state. The parameter descriptions are good, but the overall context for the operation is incomplete.

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

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

The schema has 0% description coverage, but the description adds meaningful explanations for all parameters: order_id as 'Internal order ID', file_url as 'Publicly accessible URL of the file to attach', and file_name as 'Display name for the file (optional, defaults to the URL filename)'. This significantly helps an agent understand parameter values.

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: 'Attach a file (by URL) to an order.' It uses a specific verb ('Attach') and resource ('file to an order'), and the purpose is distinct from sibling tools like 'order_add_note'.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or when not to use it.

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

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

No annotations provided, so the description carries the full burden. It does not disclose whether notes are appended, if there are length limits, permission requirements, or any side effects beyond adding a note.

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 with no wasted words. Parameters are listed clearly in a structured format, making it easy to scan.

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

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

For a simple mutation tool, the description covers the basic functionality. However, it lacks details on behavior (e.g., if notes are appended or overwritten) and usage context. Since an output schema exists, return values are not needed, but the description still feels minimal.

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 0% schema description coverage, the description compensates well by explaining each parameter: order_id as 'Internal order ID', note as 'Note text', is_public with default false. This adds value beyond the schema's type information.

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 'Add a note to an order', which is a specific verb and resource. It distinguishes itself from sibling tools like order_add_file or order_create by focusing on notes.

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

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

No guidance on when to use this tool vs alternatives (e.g., order_add_file). No mention of prerequisites or exclusions. The description only lists parameters.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only describes input structure and gives an example but omits critical details such as whether creation is synchronous, what is returned, authentication requirements, or side effects (e.g., duplicate 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?

The description is somewhat lengthy due to detailed parameter listing and a large JSON example. While informative, it could be more concise without losing clarity; the structure is functional but not optimal for quick scanning.

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

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

Given the tool's complexity (single parameter with nested object) and the existence of an output schema, the description sufficiently documents input structure. However, it could briefly mention the return value or confirmation, though not required due to output schema.

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

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

The schema defines a single string parameter 'data' with 0% description coverage. The description compensates fully by detailing the JSON structure, key fields, and providing a complete example, adding significant meaning 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 'Create a new order.' The verb 'create' and resource 'order' directly indicate the tool's function, distinguishing it from sibling tools like order_list, order_update_status, etc.

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

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

No guidance on when to use this tool versus alternatives (e.g., order_update_status for status changes, order_add_file for attachments). No prerequisites or context for usage are provided.

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

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

With no annotations present, the description does not disclose behavioral traits such as that it is a read operation, whether results are paginated (though page/limit params suggest it), or any defaults or side effects. It only lists parameter meanings.

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 clean, bullet-like list of parameters with clear one-line explanations. No extraneous information; 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 the presence of an output schema (not shown but indicated), the description adequately covers the input parameters. It does not describe the return format or behavior, but the output schema presumably covers that. The parameter descriptions are sufficiently complete for a listing 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 description coverage is 0%, so the description fully compensates by explaining each parameter's purpose (e.g., 'Filter by internal order ID'). It also specifies date format (YYYY-MM-DD) and limit range (1–100), adding value beyond the schema's titles.

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 'List orders from the Gomag store,' identifying the verb 'list' and resource 'orders.' This distinguishes it from sibling tools like 'order_create' or 'order_status_types,' though it does not explicitly contrast with them.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., 'order_status_types' for status keys, 'order_create' for creation). No prerequisites or context for usage 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?

With no annotations, the description carries full burden. It implies a read-only operation but doesn't disclose authentication requirements, rate limits, or whether the list is static/dynamic. Adequate for a simple list retrieval but lacking depth.

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

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

Single sentence that is front-loaded and concise. Every word adds value with no 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 low complexity, no params, no annotations, and existence of output schema, the description is complete. It sufficiently explains the tool's purpose without needing additional details about return values.

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

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

No parameters exist, so baseline is 4. Description correctly indicates no inputs needed, adding no extra parameter info since none are required.

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

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

Description clearly states verb 'return', resource 'list of available order status types', and scope 'defined in the store'. Distinguishes itself from sibling tools like 'order_list' which returns orders, not status 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?

No guidance on when to use this tool versus alternatives. Does not mention prerequisites or contexts where it would be 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 explains that the tool updates order status, optionally sends a notification email (notify_customer), and attaches an internal note (note). It does not mention whether changes are reversible or any permission requirements, but covers the key behaviors clearly.

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 begins with a clear one-line purpose, then efficiently lists all parameters with explanations. It is concise with no redundant information, and every sentence serves a purpose.

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

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

Given the presence of an output schema, the description does not need to explain return values. It covers the purpose and all parameters adequately. However, it lacks information about what happens after the update (e.g., success response, side effects) and does not mention any prerequisites or error conditions.

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 significant meaning beyond the input schema, which only provides titles and types. It explains order_id as 'Internal order ID', status as 'New status key' with examples and reference to order_status_types, notify_customer as 'Send a notification e-mail', and note as 'Optional internal note'. Since schema coverage is 0%, the description fully compensates.

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

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

The description clearly states 'Update the status of an existing order' with a specific verb and resource. It distinguishes itself from sibling tools like 'order_list' and 'order_create' by focusing on status updates, and further clarifies by listing the parameters involved.

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 directs the user to 'Use order_status_types() to see available values' for the status parameter, providing explicit guidance on valid inputs. It implies when to use this tool (status updates) but does not explicitly state when not to use it or mention alternative tools for other order modifications.

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 present, so the description bears full responsibility. It only states it returns a list, but does not disclose potential behavioral traits such as authentication requirements, ordering, caching, or whether the list is all payment methods or filtered.

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

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

A single sentence with 10 words, front-loaded with action and resource. Every word is necessary and there is 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?

Output schema exists, so return values are documented elsewhere. The description is brief but covers the core purpose. It might benefit from mentioning if the list is filtered by store context, but given no parameters, 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?

There are no parameters, so the schema provides full coverage. The description adds no parameter information, but with zero parameters, the baseline is 4. It does not need to add anything 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?

Description clearly states the action ('Return the list') and resource ('payment methods available in the store'). It is specific and distinguishes itself from all sibling tools, none of which deal with payment methods.

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

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

No explicit when-to-use or alternatives are provided. The tool's simplicity implies its use (when needing payment methods), but there is no guidance on exclusions or when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as idempotency, authorization needs, error behavior, or side effects beyond 'create.' The description lacks transparency about what happens on duplicate names or partial failures.

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 well-structured with a clear purpose, parameter breakdown, and example. It uses separate sections and is concise with no wasted sentences.

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

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

Given the tool has an output schema, the description doesn't need to explain returns. It fully covers input complexity (nested product objects, i18n, multiple versions). It is complete for a creation tool with no annotations.

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% (the schema only says 'data' is a string). The description compensates fully by detailing the JSON array structure, listing all possible fields (name, description, enabled, vat, currency, brand, categories, versions) with types and an example. This adds significant meaning 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 'Create one or more products,' which is a specific verb+resource. It distinguishes from sibling tools like product_list, product_update, product_delete, and product_update_inventory.

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 basic usage context but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or 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?

No annotations are provided, and the description fails to disclose important behavioral traits such as irreversibility, permissions required, impact on related data, or whether deletion is hard or soft. The description only states the action without behavioral context.

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

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

The description is concise with a clear purpose line and parameter explanation. The example adds value. It could be slightly improved with bullet points for the parameter description, but overall efficient.

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

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

Given the simplicity of the tool and presence of an output schema, the description covers the basic usage. However, it lacks context on error handling, permissions, and whether deletion is permanent or reversible, which is important for a destructive operation.

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

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

The parameter 'data' is explained with format ('JSON array of objects'), content ('each object should contain either id or sku'), and an example. This fully compensates for the schema's lack of description (0% coverage).

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

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

The description clearly states the action ('Delete products') and the method of identification ('by SKU or ID'), distinguishing it from sibling tools like product_create, product_list, and product_update.

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 an example but does not explicitly state when to use this tool versus alternatives (e.g., product_update_inventory for inventory changes, product_update for modifications). Usage context is implied by the name and example.

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 convey safety. The verb 'List' strongly implies a read-only operation, but the description does not explicitly state that it does not modify data or disclose any side effects, authentication, or rate limits.

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 begins with a short, direct sentence followed by a clean parameter list. It is well-organized and free of fluff, though the table header 'Parameters ----------' could be omitted for even tighter structure.

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

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

With 12 parameters and no annotations, the description logically explains each filter. Since an output schema exists, it need not detail return values. The description is adequately complete for a listing tool, though it could mention pagination behavior or typical response structure.

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

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

The input schema provides no descriptions (0% coverage), but the description compensates fully by explaining each parameter's purpose, including type constraints (e.g., page number, limit range 1–100, date format YYYY-MM-DD, boolean toggles, language code). This adds significant value beyond the raw 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 verb 'List' and the resource 'products from the Gomag store'. It is concise and distinct from sibling tools that create, update, or delete products.

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

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

The description implies usage for listing products but provides no explicit guidance on when to use this tool over alternatives, nor does it specify when not to use it. The parameter list gives filtering options but lacks comparative 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 mentions 'patch' but doesn't disclose side effects, authorization needs, or whether omitted fields are preserved or cleared. Lacks key behavioral details.

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

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

Description is concise with a clear structure: brief statement, parameters bullet, and example. 'Parameters' section is slightly redundant but overall efficient.

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

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

Output schema exists but description doesn't mention return values. Also lacks error handling or atomicity details. Adequate but has gaps.

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

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

Schema coverage is 0%, but description adds significant meaning: data is a JSON array of partial objects with required identifier and fields. Example clarifies the format. 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?

Description clearly states 'Update (patch) existing products' - specific verb and resource. Differentiates from sibling tools like product_create and product_delete.

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?

Implies usage for updating product fields, but no explicit when-to-use or when-not-to-use. Alternatives like product_update_inventory exist but not 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?

With no annotations provided, the description partially fulfills the burden by indicating mutation ('Bulk-update'). However, it lacks details on atomicity, error handling, or batch behavior, which are critical for a bulk operation 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 concise and well-structured with a clear purpose, parameter list, and example. Every sentence adds value, and there is no extraneous information.

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

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

Given the presence of an output schema (not detailed here), the description adequately covers input semantics. However, it omits behavioral traits like idempotency or error responses, which would enhance completeness for a mutation 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 only defines 'data' as a string with no structure, but the description fully details the JSON array format, required and optional fields (sku, price, stock, specialPrice), and includes an example. This adds significant meaning beyond the schema, compensating for zero schema coverage.

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

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

The description states 'Bulk-update product price and/or stock (inventory sync),' clearly specifying the verb ('Bulk-update') and resource ('product price and/or stock'). It effectively distinguishes from sibling tools like product_create or product_update by focusing on inventory sync.

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 'inventory sync' but does not provide explicit guidance on when to use this tool versus alternatives (e.g., product_update). There is no indication of prerequisites or when not to use it, leaving the agent without clear selection criteria.

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?

Without annotations, the description must disclose behavioral traits. It mentions the 'approved' parameter and its default to store's setting, which hints at moderation behavior. However, it does not state what happens after submission (e.g., visibility, notifications), whether duplicates are allowed, or any side effects.

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

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

The description is front-loaded with a purpose statement but then repeats parameter names and descriptions in a list format, which is somewhat redundant given the schema. It could be more concise by focusing on unique behavioral details rather than paraphrasing schema fields.

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?

Even though an output schema exists, the description does not inform the agent about what the tool returns (e.g., created review ID, status, errors). This is critical for a creation tool, and its omission leaves the agent without a complete mental model.

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?

Despite 0% schema description coverage, the inline parameter list adds meaningful context: 'Star rating (1–5)', 'Short review title/summary', and 'Set approval status immediately'. This compensates well for the schema's sparse type-only meanings, though some parameters (e.g., 'content') lack additional semantics.

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

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

The description clearly states the action ('Submit') and the resource ('a product review'), making its core purpose unambiguous. It is distinct from the sibling 'review_list' tool, though it doesn't explicitly distinguish itself from other create tools.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., when to use review_list or other creation tools). There are no prerequisites, when-not-to-use conditions, or context about intended use cases.

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 carry the full burden. It only states 'List product reviews' and lists parameters, but fails to disclose pagination behavior, ordering, authentication needs, or any side effects. The existence of an output schema is not leveraged to describe return 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 extremely concise: a one-line header followed by a well-formatted parameter list. Every sentence is necessary and no information is redundant.

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 adequately explains parameters and pagination limits (1–100), but does not clarify default behavior (e.g., all reviews returned if no filters), ordering, or how to interpret the output. Given the presence of an output schema, the lack of return value details is acceptable, but some usage context is missing.

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

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

Schema description coverage is 0%, but the description compensates by providing brief explanations for all five parameters (e.g., 'Filter by product ID', 'Results per page (1–100)'). This adds meaningful context beyond the schema titles and types.

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 'List product reviews,' specifying the action (list) and resource (product reviews). Among sibling tools, there is no other review list tool, so it is well-distinguished.

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

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

No guidance on when to use this tool versus alternatives. The description only lists parameters without explaining selection criteria or comparison to other list tools like product_list or customer_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 must disclose behavioral traits. It indicates this is a creation/mutation operation and lists parameters and an example. However, it does not mention idempotency, error handling, authentication needs, or side effects like overwriting existing rules. This is adequate but not comprehensive.

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

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

The description is well-organized with a clear header, bulleted parameter list, and example. It is moderately concise; every sentence adds value. The example takes some space but is useful. Could be slightly tightened, but overall efficient.

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

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

For a tool creating a cart rule with many fields, the description thoroughly documents the data structure. The presence of an output schema (not shown but indicated) covers return values. Missing are error scenarios or post-creation behavior, but the description is sufficient 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?

The input schema has only a single 'data' parameter of type string with 0% description coverage. The description fully compensates by detailing the expected JSON structure, including all key fields, their types, optionality, and an example. This adds critical meaning 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 starts with 'Create a shopping cart rule (discount / promotion)', which clearly states the action (create) and the resource (shopping cart rule). It distinguishes itself from sibling creation tools like product_create or category_create by being specific to cart rules.

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

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

The description does not explicitly state when to use this tool or when to avoid it. It provides parameter details but lacks guidance on alternatives or exclusions. The usage is implied as 'when you need to create a discount rule', but no explicit context is given.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It fails to mention idempotency, side effects, error conditions, or any operational details like whether duplicate additions are handled.

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

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

The description is short and gets to the point, though it redundantly repeats parameter names already in schema. Could be more concise by integrating params inline.

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

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

For a mutation tool with no annotations, no guidance on output, and minimal parameter explanation, the description is notably incomplete. Output schema exists but is not referenced.

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 description must compensate. It adds only 'internal ID' context to parameters, which is slightly more than schema but still very minimal. Lacks any format, constraints, or usage hints.

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 'Add' and the resource 'a product to a customer's wishlist', distinguishing it from siblings like wishlist_remove and wishlist_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?

No guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it. Only states the basic action.

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. Description implies a read operation with no side effects, but does not explicitly confirm non-destructiveness, rate limits, or authentication needs.

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

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

Concise: one sentence for purpose followed by a bullet list of parameters. 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?

Given output schema exists, return values need not be explained. The description covers purpose and parameters fully, but could add guidance on pagination or identifier usage.

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

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

Description adds brief explanations for each parameter beyond schema property titles (e.g., 'Customer's internal ID', '1–100'). However, it does not clarify whether customer_id and email are mutually exclusive or if one 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?

Description clearly states 'List a customer's saved (wishlist) products', specifying verb and resource. It distinguishes from sibling tools wishlist_add and wishlist_remove which handle mutations.

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