Kash.click

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

Annotations indicate openWorldHint=true, idempotentHint=false, and destructiveHint=false, which already inform the agent about safety and idempotency. The description adds no behavioral context beyond these annotations, such as authentication requirements, rate limits, or side effects. However, it does not contradict the annotations, so it meets the lower bar set by their presence.

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 placeholder string 'tools.account_create.description' that is not front-loaded with useful information. It lacks any structure or meaningful content, failing to convey purpose or usage in an efficient manner, which is a severe deficiency rather than conciseness.

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

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

Given the complexity of a 12-parameter tool with no output schema, the description is completely inadequate. It does not explain what the tool does, when to use it, or what it returns, leaving significant gaps in understanding despite the well-documented input schema and 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 description coverage is 100%, with each parameter clearly documented in the input schema (e.g., 'email' as 'Email address for the new Kash account'). The description adds no additional meaning or context about parameters, so it defaults to the baseline score of 3, as the schema adequately handles parameter semantics.

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

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

The description is a tautology that merely restates the tool name 'tools.account_create.description' without providing any meaningful information about what the tool does. It fails to specify the verb (e.g., 'create') or the resource (e.g., 'a new Kash account'), and offers no differentiation from sibling tools like 'account_list' or 'client_add'.

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. It does not mention prerequisites, context, or exclusions, leaving the agent with no information to decide between this tool and other account-related or creation tools like 'client_add' or 'order_create'.

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

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

Annotations indicate non-destructive and non-idempotent behavior. The description reinforces that all fields are optional (partial update allowed) and lists specific categories, which provides good context beyond annotations. No contradictions with annotations.

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

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

The description is concise, front-loading the core purpose and then listing categories. It covers many aspects without being verbose. Could be slightly improved by structuring the list more clearly.

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 high parameter count (81) and full schema coverage, the description provides a useful overview. However, it lacks mention of return values or error states, though no output schema exists. The tool is a straightforward update, so completeness is adequate.

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

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

Schema description coverage is 100%, so the schema already provides adequate parameter descriptions. The description adds high-level categories but does not explain parameter interactions or constraints (e.g., enable_whiteLabel cannot be disabled once enabled is a critical behavior mentioned only in the schema).

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

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

The description clearly states the tool modifies authenticated shop account settings, covering a wide range of categories (basic info, receipt display, feature flags, etc.). It distinguishes itself from siblings like account_create and account_list by focusing on editing existing settings.

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

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

The description notes all fields are optional, implying the tool can be used for partial updates. However, it does not specify when to use this tool versus other account-related tools (e.g., account_show_infos for reading), nor does it mention any prerequisites like authentication or the need to fetch current settings first.

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

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

Annotations indicate readOnlyHint=true, which the description doesn't contradict. However, the description adds no behavioral context beyond this, such as rate limits, authentication needs, or output format. With annotations covering safety, the description minimally meets baseline by not misleading, but adds no value.

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

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

The description 'tools.account_list.description' is a placeholder string that lacks any meaningful content. It is not appropriately sized or structured, failing to convey information efficiently and appearing as an under-specified template rather than a concise tool description.

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 annotations and a well-documented input schema but no output schema, the description is incomplete. It doesn't explain what the tool returns or its behavior, leaving gaps despite structured fields. For a list tool with sibling alternatives, more context is needed for effective use.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters (email and accountTitle). The description adds no additional meaning or context about parameters beyond what the schema provides, so it meets the baseline score of 3 without compensating or enhancing understanding.

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

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

The description 'tools.account_list.description' is a placeholder that doesn't provide any meaningful information about what the tool does. It doesn't specify the verb or resource, making the purpose vague. However, the tool name 'account_list' suggests it likely lists accounts, but this is only inferred, not stated.

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

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

The description provides no guidance on when to use this tool versus alternatives. There are no explicit or implied usage instructions, prerequisites, or comparisons to sibling tools like 'account_create' or other data_list tools, leaving the agent with no context for selection.

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

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

Annotations declare readOnlyHint=true, which the description aligns with by stating it retrieves settings. The description adds behavioral context: it returns a full JSON object of shop configuration and can be used to check invoice prerequisites. It does not contradict annotations.

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

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

The description is concise (three sentences) and front-loaded with the primary action. Every sentence serves a purpose: first states what it does, second lists what it returns, third provides actionable usage guidance.

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 no parameters and no output schema, so the description is complete enough. It explains the return value and provides context for when to use it, making it fully adequate for an agent to select and invoke the tool correctly.

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

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

The input schema has no parameters and schema description coverage is 100%. The description adds value by explaining what the output contains and how it can be used, but since there are no parameters, the score is based on the description's clarity about the tool's no-parameter behavior.

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

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

The description clearly states the tool retrieves all current settings of the authenticated shop account as a JSON object. It lists the specific configuration fields returned (name, address, legal numbers, etc.), making it distinct from siblings like account_edit which modifies settings.

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

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

The description explicitly tells when to use this tool: to verify invoice prerequisites before creating orders. It specifies that shopName, adressline1, and companyRegistrationNum must be set for legally valid invoices, and instructs the agent to prompt the user to fill in missing fields via account_edit.

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

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

Annotations indicate non-idempotent and non-destructive behavior, which the description doesn't contradict. The description adds valuable behavioral context beyond annotations: it explains that this tool initializes a session automatically ('automatically initialize the session so all other tools work immediately'), which is crucial for understanding its side effects and integration with other tools.

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 the core purpose, followed by prerequisites and outcomes in two efficient sentences. Every sentence earns its place by providing essential information without redundancy.

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

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

Given the tool's complexity (authentication flow with session initialization), no output schema, and annotations covering safety, the description is largely complete. It explains the authentication sequence, prerequisites, and session initialization. A minor gap is lack of detail on return values (e.g., what APIKEY and SHOPID look like), but this is partially mitigated by the tool's purpose being clear.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (email and OTP). The description adds minimal semantic value beyond the schema, only reiterating that the OTP is 'received by email' and the email is 'used to request the OTP', which is already implied. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Exchange the OTP received by email for an APIKEY and SHOPID') and resource (authentication session), distinguishing it from sibling tools like auth_request_otp by specifying it as 'Step 2 of 2' and contrasting with the first step.

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

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

Explicitly states when to use ('Step 2 of 2 for in-conversation authentication'), when not to use (implies not to use without first calling auth_request_otp), and names the alternative tool ('Call auth_request_otp first'). This provides clear contextual guidance.

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

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

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate idempotency and non-destructiveness, the description clarifies that this clears authentication credentials and makes subsequent authenticated operations fail until re-authentication. This provides important operational context that annotations alone don't convey.

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 perfectly concise with two sentences that each earn their place: the first states the action, the second explains the consequences. It's front-loaded with the core purpose and wastes no words while providing complete operational guidance.

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

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

For a zero-parameter tool with idempotent and non-destructive annotations, the description provides exactly what's needed: clear action statement, immediate consequences, and operational implications. No output schema exists, but the description adequately explains what happens after invocation without needing return value details.

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 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this tool's design. No parameter information is needed or missing.

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 specific action ('Clear the current authentication session') and identifies the exact resources affected ('APIKEY and SHOPID'). It distinguishes this tool from all sibling tools by focusing exclusively on session termination rather than data operations or other authentication 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?

The description explicitly states when to use this tool ('After this, all tools requiring authentication will fail until a new login is performed'), providing clear context about the consequences and timing. It effectively distinguishes this from authentication-establishing tools like auth_login_with_otp and auth_request_otp.

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

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

Annotations indicate this is a non-readOnly, non-idempotent, open-world operation, which the description aligns with by describing an OTP-sending action. The description adds valuable context beyond annotations: it specifies the delivery method ('sent by email'), clarifies the multi-account handling logic, and outlines the two-step authentication workflow, though it doesn't mention rate limits or error conditions.

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

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

Three sentences that are front-loaded with the core purpose, followed by conditional logic and next steps. Every sentence earns its place by providing essential information without redundancy or fluff.

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

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

For a 2-parameter authentication tool with no output schema, the description is mostly complete: it explains the purpose, workflow, parameter conditions, and next step. It could be more complete by mentioning error cases or response format, but given the annotations and clear schema, it's sufficient for agent 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?

With 100% schema description coverage, the baseline is 3. The description adds some semantic context by explaining when to use accountID ('if the user has multiple accounts') and referencing account_list as the source, but doesn't provide additional syntax or format details beyond what's in the 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 specific action ('Sends a one-time password (OTP) to the user's email address') and resource ('for in-conversation authentication'), distinguishing it from sibling tools like auth_login_with_otp by positioning it as 'Step 1 of 2' in the authentication flow.

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

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

Explicitly states when to use ('Step 1 of 2 for in-conversation authentication') and when not to use (implied: not for other authentication methods), provides an alternative for multi-account scenarios ('If the user has multiple accounts, provide accountID'), and specifies the next step ('then call auth_login_with_otp with that code').

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

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

Annotations indicate idempotentHint=false and destructiveHint=false, which the description doesn't contradict. The description adds useful context about field optionality ('All fields are optional') and the duplicate-check recommendation, but doesn't provide additional behavioral details like error conditions, response format, or permission requirements that would be valuable for a creation tool.

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

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

The description is efficiently structured in two sentences: the first states the purpose and field optionality, the second provides crucial usage guidance. While the field listing could be more concise (using 'etc.' helps), the information is front-loaded and each sentence serves a clear purpose.

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

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

For a creation tool with no output schema, the description provides good contextual coverage: it clarifies the purpose, gives usage guidance, and indicates field optionality. However, it doesn't describe what happens on success/failure or the response format, which would be helpful given the absence of output schema. The annotations provide basic safety information but don't fully compensate.

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 100% schema description coverage, the schema already documents all 25 parameters thoroughly. The description adds minimal value by listing some example fields (name, surname, email, etc.) and stating they're optional, but doesn't provide additional semantic context beyond what's in the parameter descriptions. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Add a new customer') and resource ('to the shop's customer file'), distinguishing it from sibling tools like client_delete, client_edit, and data_list_clients. It precisely communicates the creation function without ambiguity.

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

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

The description explicitly provides usage guidance by stating 'Use data_list_clients to check if the customer already exists first,' naming a specific alternative tool for validation. This gives clear context on when to use this tool versus alternatives, addressing a common prerequisite scenario.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context with 'permanently remove' (reinforcing destructiveness) and 'from the shop's customer file' (clarifying scope). It doesn't contradict annotations and provides additional behavioral insight beyond the structured hints.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse quickly.

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

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

For a destructive tool with one parameter and good annotations, the description is reasonably complete. It clarifies the permanent nature of deletion and the target resource. However, without an output schema, it doesn't describe return values or error conditions, leaving some gaps in full context.

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

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

Schema description coverage is 100% with the parameter 'id' fully documented as 'ID of the customer to delete'. The description adds minimal value beyond the schema by mentioning 'by their ID', but doesn't provide additional syntax, format, or constraints. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the action ('permanently remove'), target resource ('a customer from the shop's customer file'), and identifier mechanism ('by their ID'). It distinguishes from sibling tools like client_add and client_edit by specifying deletion rather than creation or modification.

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 customer needs to be permanently removed, but doesn't explicitly state when to use this tool versus alternatives like client_edit for updates or data_list_clients for viewing. No guidance on prerequisites or exclusions 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?

Annotations provide idempotentHint=true and destructiveHint=false, indicating safe, repeatable operations. The description adds that 'All fields are optional except the ID,' which clarifies partial updates are allowed. However, it doesn't mention authentication requirements, rate limits, or what happens when invalid data is provided. No contradiction with annotations exists.

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

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

Two sentences with zero waste: first states purpose and key constraint, second provides practical usage guidance. Every word earns its place, and information is front-loaded appropriately for an agent.

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 26 parameters and no output schema, the description is adequate but minimal. Annotations cover safety (idempotent, non-destructive), and schema covers parameters completely. However, the description doesn't explain what the tool returns or potential error conditions, which would be helpful given the complexity.

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

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

Schema description coverage is 100%, with each parameter well-documented in the schema. The description adds that 'All fields are optional except the ID,' which reinforces the schema's required field but doesn't provide additional semantic context beyond what's already in the parameter descriptions. Baseline 3 is appropriate given complete schema coverage.

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

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

The description clearly states the action ('Edit an existing customer') and resource ('by their ID'), making the purpose unambiguous. It distinguishes from 'client_add' (create) and 'client_delete' (remove), but doesn't explicitly differentiate from other edit tools like 'dept_edit' or 'vat_edit' which operate on different resources.

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

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

The description provides clear context for when to use this tool: 'Edit an existing customer by their ID' and 'Use data_list_clients to find the customer ID first.' This gives practical guidance on prerequisites. However, it doesn't explicitly state when NOT to use this tool or mention alternatives like 'client_add' for new customers.

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

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

Annotations provide readOnlyHint=true, which the description aligns with by describing a listing operation. The description adds valuable context beyond annotations by specifying what information is included (status and identifiers) and clarifying the scope (physical or virtual cashboxes linked to the shop). No contradiction with annotations.

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

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

Single sentence efficiently conveys purpose, scope, and output details. No redundant information or unnecessary elaboration. Well-structured and front-loaded with the core 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?

For a simple read-only listing tool with one optional parameter and good annotations, the description provides adequate context. It explains what's returned (status and identifiers) and scope, though it could mention pagination or ordering if relevant. No output schema exists, but the description gives reasonable output expectations.

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

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

Schema description coverage is 100%, with the single parameter 'format' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline for high schema coverage.

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

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

The description clearly states the verb ('List') and resource ('registered cashboxes'), specifies the scope ('linked to the shop'), and distinguishes from siblings by focusing on cashboxes rather than clients, orders, products, etc. It adds useful detail about including 'current status and identifiers'.

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 (when you need cashbox information), but doesn't explicitly state when to use this tool versus alternatives. No guidance on prerequisites, timing, or comparisons with other list tools 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?

Annotations provide readOnlyHint=true, indicating this is a safe read operation. The description adds context by specifying what data is included ('contact info, loyalty points'), which goes beyond the annotations. However, it doesn't disclose behavioral traits like pagination, rate limits, or authentication needs, leaving gaps in transparency despite the annotations covering safety.

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, efficient sentence that front-loads the core action ('Get the list') and includes key details. It avoids unnecessary words, but could be slightly more structured by separating the purpose from the data inclusions for better clarity.

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

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

Given the tool's low complexity (1 parameter, read-only per annotations) and no output schema, the description is minimally adequate. It covers the purpose and data scope, but lacks details on usage context, behavioral aspects like response handling, or integration with sibling tools, making it incomplete for optimal agent guidance.

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

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

Schema description coverage is 100%, with the parameter 'format' fully documented in the schema (enum values, default, description). The description adds no additional meaning about parameters beyond what the schema provides, such as explaining when to use different formats. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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 ('Get') and resource ('list of clients registered in the shop'), specifying what data is included ('contact info, loyalty points'). However, it doesn't explicitly differentiate from sibling tools like 'client_add', 'client_edit', or 'client_delete', which are related but perform different operations on clients.

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. It doesn't mention scenarios like retrieving client data for reporting versus editing client details, nor does it reference sibling tools like 'client_edit' for updates or 'data_list_orders' for related data. Usage is implied by the action 'Get the list', but no explicit context or exclusions 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?

Annotations declare readOnlyHint=true, which the description aligns with by describing a listing operation. The description adds context about what types of delivery methods might be returned (e.g., in-store pickup), which is valuable beyond the annotations. However, it doesn't mention rate limits, pagination, 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?

The description is a single, efficient sentence that front-loads the purpose and provides examples without unnecessary details. Every word contributes to understanding the tool's function.

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

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

For a simple read-only listing tool with one optional parameter and no output schema, the description is reasonably complete. It covers the purpose and scope well, though it could benefit from more behavioral details like response structure or error handling.

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

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

The input schema has 100% description coverage, fully documenting the 'format' parameter with enum values and default. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline for high schema coverage.

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

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

The description clearly states the verb 'List' and the resource 'delivery methods available for the shop', with specific examples like 'in-store pickup, home delivery, or courier services'. It distinguishes from siblings like data_list_orders or data_list_products by focusing on delivery 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?

The description implies usage when needing to know available delivery methods, but provides no explicit guidance on when to use this versus alternatives like data_list_delivery_zones or other data_list_* tools. It lacks clear exclusions or 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?

Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds context about what data is returned (area names, postal codes, fees/restrictions), which is useful beyond annotations. However, it lacks details on pagination, rate limits, or error conditions, limiting behavioral insight.

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, efficient sentence that front-loads the core purpose and details without waste. Every word contributes to understanding the tool's function and output.

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

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

Given the tool's low complexity (1 optional parameter, read-only, no output schema), the description is reasonably complete. It covers what data is returned, but could improve by addressing potential limitations (e.g., large result sets) or linking to related tools for more context.

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

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

Schema description coverage is 100%, with the 'format' parameter fully documented in the schema (enum values and default). The description does not add any parameter-specific information beyond the schema, so it meets the baseline for high coverage without compensation.

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') and resource ('all configured delivery zones'), specifying the included data fields (area names, postal codes, delivery fees/restrictions). It distinguishes from siblings like 'data_list_clients' or 'data_list_products' by focusing on delivery zones.

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 versus alternatives is provided. The description does not mention prerequisites, timing, or comparisons with other list tools (e.g., 'data_list_relay_points'), leaving usage context implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about the purpose of department groups (organizing product categories, containing multiple department IDs), but doesn't disclose behavioral traits like rate limits, authentication needs, or pagination behavior. No contradiction with annotations exists.

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

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

The description is two concise sentences with zero waste: the first states the core action, and the second adds valuable context about department groups. It's appropriately sized and front-loaded with the essential information.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description is adequate but minimal. It explains what department groups are but doesn't cover response format details, error cases, or usage scenarios, leaving some gaps in contextual understanding.

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

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

Schema description coverage is 100%, with the single parameter 'format' fully documented in the schema (enum values, default, description). The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline for high 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 verb ('Return') and resource ('list of department groups'), explaining that these groups organize product categories and contain multiple department IDs. However, it doesn't explicitly differentiate from sibling tools like 'data_list_departments' or 'data_list_products', which would require a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'data_list_departments' or 'data_list_products', nor does it mention prerequisites or exclusions. It only states what the tool does, not when it's 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?

Annotations declare readOnlyHint=true, which the description aligns with by using 'Get' (a read operation). The description adds valuable context beyond annotations: it specifies the output includes names and tax rates, and mentions format support, which helps the agent understand behavioral traits like response customization.

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, efficient sentence that front-loads the core purpose and includes essential details (content and format support) without waste. Every part earns its place, making it highly concise and well-structured.

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

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

Given the tool's low complexity (1 optional parameter, read-only annotation, no output schema), the description is mostly complete. It covers purpose, content, and format, but could improve by mentioning pagination or error handling. However, it's sufficient for basic use.

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

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

Schema description coverage is 100%, with the parameter 'format' fully documented in the schema. The description mentions format options but doesn't add meaning beyond what the schema provides (e.g., default behavior or implications of each format). Baseline 3 is appropriate as the schema carries the burden.

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 ('Get') and resource ('all departments'), specifies the content ('including their names and default tax rates'), and distinguishes from siblings like 'data_list_department_groups' by focusing on product categories. It's 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 implies usage for retrieving department data but doesn't explicitly state when to use this tool versus alternatives like 'data_list_department_groups' or 'dept_add'. It provides some context with format options but lacks guidance on prerequisites 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?

Annotations provide readOnlyHint=true, which the description doesn't contradict. The description adds useful context about what fields are returned (names, types, values, conditions) and that it returns 'all available' discounts, but doesn't mention pagination, sorting, filtering capabilities, or any rate limits. With annotations covering safety, this adds moderate value.

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

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

Single sentence efficiently conveys purpose and return fields. No wasted words, front-loaded with the main action. Every element serves a purpose in describing what the tool does.

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

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

For a simple read-only list tool with good annotations and full schema coverage, the description is adequate but minimal. It covers what data is returned but lacks context about filtering, ordering, or result format implications. Without output schema, more detail about return structure would be helpful.

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

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

Schema description coverage is 100% with one parameter fully documented. The description doesn't mention the format parameter at all, nor does it provide additional context about parameter usage. Since the schema does all the parameter documentation work, baseline 3 is appropriate.

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

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

The description clearly states the verb 'return' and resource 'discounts or promotions' with specific attributes (names, types, values, conditions). It distinguishes from some siblings like 'data_list_orders' by specifying the discount domain, but doesn't explicitly differentiate from other data_list_* tools that also return lists of different resources.

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. It doesn't mention prerequisites, timing considerations, or compare it to other list tools like 'data_list_products' or 'data_list_clients'. The agent must infer usage from the tool name alone.

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

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

The readOnlyHint annotation already indicates this is a safe read operation. The description adds useful context about the two different order types and their date filtering logic, but doesn't disclose behavioral aspects like pagination, rate limits, or authentication requirements beyond what annotations provide.

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

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

The description is appropriately sized with two sentences that efficiently convey the tool's dual functionality. It's front-loaded with the main purpose, though the second sentence could be slightly more concise by integrating the filterDeliveryMethod mention more smoothly.

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

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

For a read-only list tool with comprehensive schema documentation, the description provides adequate context about the tool's dual functionality and filtering logic. However, without an output schema, it could benefit from mentioning what the response contains (e.g., order objects with specific fields).

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 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds marginal value by explaining the semantic difference between date filtering for validated vs unvalidated orders, but doesn't provide additional parameter details beyond what's in the schema.

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

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

The description clearly states the verb 'List' and resource 'orders', specifying two distinct types (unvalidated orders/quotes vs validated orders/invoices) with their respective date filtering criteria. It distinguishes from sibling tools like data_list_pending_orders by covering both validated and unvalidated orders in one 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?

The description provides clear context for when to use the tool (listing orders with date filtering) and distinguishes between the two order types based on the validatedOrders parameter. However, it doesn't explicitly state when NOT to use this tool or mention alternatives like data_list_pending_orders for pending orders only.

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

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

The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds no behavioral context beyond what annotations provide - no information about pagination, rate limits, authentication requirements, or what specific payment data is returned. However, it doesn't contradict the annotations.

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

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

While technically concise (one placeholder string), this is under-specification rather than effective conciseness. The description fails to communicate any useful information and doesn't follow the principle that every sentence should earn its place.

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

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

For a list tool with read-only annotations but no output schema, the description is severely inadequate. It doesn't explain what payment data is returned, the scope of listings, or any behavioral characteristics. The agent would have to guess what this tool actually provides.

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 100% schema description coverage and only one optional parameter (format with clear enum values and default), the schema fully documents the parameter. The description adds no additional semantic context about the format parameter or its implications for the response.

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

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

The description is a tautology that merely restates the tool name ('tools.data.list.payments.description'), providing no meaningful information about what the tool actually does. It doesn't specify what 'payments' refers to, what data is listed, or how it differs from other list tools like data_list_orders or data_list_clients.

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 absolutely no guidance on when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparison to sibling tools like data_list_orders or data_list_cashboxes that might handle related data.

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

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

Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds context about the type of orders (unvalidated and modifiable), which is useful beyond annotations. However, it does not disclose other behavioral traits like pagination, 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?

The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose and includes a clarifying qualifier, making it appropriately sized and structured.

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

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

Given the tool's low complexity (one optional parameter), high schema coverage, and read-only annotation, the description is mostly complete. However, without an output schema, it could benefit from mentioning the return structure (e.g., list of orders), but the context is sufficient for basic use.

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

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

Schema description coverage is 100%, so the schema fully documents the 'format' parameter with enum values and default. The description adds no parameter-specific information beyond what the schema provides, meeting the baseline for high 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 verb 'retrieve' and the resource 'list of unvalidated orders', with the qualifier 'that can still be modified' distinguishing it from sibling tools like 'data_list_orders' (which likely lists all orders). This is specific and avoids tautology.

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 unvalidated/modifiable orders, but does not explicitly state when to use this versus alternatives like 'data_list_orders' or 'order_detail'. It provides some context but lacks clear exclusions or named alternatives.

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

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

Annotations indicate readOnlyHint=true, which the description aligns with by implying a safe read operation ('Retrieve'). It adds context about the return format (array of products with specific fields) and optional parameter behavior, but doesn't cover aspects like rate limits or pagination.

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 front-loaded, with two sentences that efficiently convey purpose and parameter information. However, the second sentence could be slightly more streamlined by integrating the parameter detail more seamlessly.

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

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

Given the tool's low complexity (1 optional parameter, read-only annotation, no output schema), the description is moderately complete. It covers the basic operation and return structure but lacks details on error handling or performance considerations, which could enhance agent understanding.

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

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

Schema description coverage is 100%, so the schema fully documents the 'format' parameter. The description adds minimal value by mentioning the parameter's optional nature and output formats, but doesn't provide extra semantic details beyond what's in the schema.

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

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

The description clearly states the verb ('Retrieve') and resource ('list of articles (products) configured in the shop'), making the purpose specific. It distinguishes from siblings like 'data_list_orders' by specifying the resource type, though it doesn't 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. While it mentions retrieving products, it doesn't specify scenarios, prerequisites, or exclusions, leaving the agent without contextual usage cues.

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

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

Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds context about what data is included (address, city, postal code), which is useful beyond annotations. However, it doesn't disclose behavioral traits like pagination, rate limits, or authentication needs, leaving gaps for a tool with no output schema.

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, efficient sentence that front-loads the purpose and includes key details without waste. Every word contributes to understanding the tool's function.

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

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

Given the tool's low complexity (1 optional parameter) and annotations covering safety, the description is minimally adequate. However, with no output schema and incomplete behavioral context (e.g., return format details), it leaves gaps that could hinder agent usage.

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

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

Schema description coverage is 100%, with the parameter 'format' fully documented in the schema. The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 without compensating or adding 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 clearly states the action ('List all relay points') and resource ('relay points where customers can pick up their orders'), with specific attributes included ('address, city, and postal code'). It distinguishes from other list tools by specifying the resource type, though it doesn't explicitly differentiate from similar list tools like 'data_list_delivery_zones'.

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. It doesn't mention prerequisites, context (e.g., after order creation), or exclusions, despite having sibling tools like 'data_list_delivery_zones' that might overlap in purpose.

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

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

Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the tool's purpose in restaurant/table management contexts, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or pagination behavior beyond what annotations cover.

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, efficient sentence that front-loads the core purpose and adds contextual usage without unnecessary details. Every word earns its place, making it appropriately 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?

For a simple read operation with one optional parameter and readOnlyHint annotation, the description provides adequate context about purpose and usage. However, without an output schema, it doesn't describe return values (e.g., table structure), leaving a minor gap in completeness.

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

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

Schema description coverage is 100%, with the single parameter 'format' fully documented in the schema (enum values, default, description). The description doesn't add any parameter-specific information beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Retrieve the list') and resource ('tables configured in the app'), and provides context about usage ('used for restaurant mode or table management'). However, it doesn't explicitly differentiate from sibling tools like 'data_list_clients' or 'data_list_products' beyond the resource type.

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 ('used for restaurant mode or table management'), which suggests when this tool might be relevant. However, it doesn't provide explicit guidance on when to use this versus alternatives (e.g., other 'data_list_' tools) or any exclusions.

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

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

Annotations indicate readOnlyHint=true, which the description aligns with by implying a read operation ('List'). The description adds context about including 'roles and identifiers', which isn't covered by annotations, but it lacks details on behavioral traits like pagination, rate limits, or authentication needs. No contradiction with annotations exists.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('List all users') and adds necessary details ('associated with the shop, including their roles and identifiers') without redundancy. Every word contributes to clarity, making it appropriately sized and well-structured.

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

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

Given the tool's low complexity (1 optional parameter) and annotations covering safety (readOnlyHint=true), the description is adequate but incomplete. It lacks output details (no output schema provided) and doesn't address usage context or sibling differentiation, leaving gaps for an AI agent to fully understand when and how to invoke it effectively.

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

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

Schema description coverage is 100%, with the 'format' parameter fully documented in the schema. The description adds no additional parameter information beyond what the schema provides, such as default behavior or usage examples, so it meets the baseline for high schema coverage without compensating 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 clearly states the verb ('List') and resource ('users'), specifying the scope as 'all users associated with the shop' and including details like 'roles and identifiers'. However, it doesn't explicitly differentiate from sibling tools like 'account_list' or 'data_list_clients', which might also list user-related entities, leaving some ambiguity about uniqueness.

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. It doesn't mention scenarios, prerequisites, or exclusions, such as how it differs from 'account_list' or when to prefer other data_list tools for specific user types like cashiers or managers.

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

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about the return format ('array of variant definitions') and content ('value and optional price delta'), which goes beyond annotations. However, it doesn't mention potential limitations like pagination, rate limits, or authentication requirements.

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

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

The description is a single, efficient sentence that front-loads the core purpose and includes essential output details. Every word contributes value with zero waste or redundancy.

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

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

For a read-only tool with one well-documented parameter and no output schema, the description provides adequate context: it clarifies the resource scope (product variations), gives examples, and describes the return structure. The main gap is lack of sibling differentiation, but overall it's reasonably complete for this complexity level.

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

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

Schema description coverage is 100%, with the single parameter 'format' fully documented in the schema (enum values, default, description). The description adds no parameter-specific information beyond what the schema provides, which is acceptable given the high schema coverage.

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

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

The description clearly states the verb ('Retrieve') and resource ('product variations'), with specific examples ('size or color') and output details ('array of variant definitions with value and optional price delta'). It distinguishes from siblings like 'data_list_products' by focusing on variations rather than products themselves, though it doesn't explicitly name alternatives.

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

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

The description implies usage when needing variant definitions, but provides no explicit guidance on when to use this tool versus alternatives like 'data_list_products' or other data_list_* siblings. No prerequisites, exclusions, or comparative context 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?

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds context about what data is included (title, rate percentage, accounting chapter), which is useful beyond the annotations. However, it doesn't disclose other behavioral traits like pagination, rate limits, or authentication requirements that might be relevant.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key details without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse.

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

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

Given the tool's low complexity (one optional parameter, read-only per annotations), the description provides sufficient context for basic use. It explains what data is retrieved, though it doesn't cover output format details (handled by the parameter) or error cases. With annotations covering safety, this is adequate for a simple list 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 100%, with the single parameter 'format' fully documented in the schema (enum values, default, description). The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating 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 clearly states the verb ('Retrieve') and resource ('list of VAT rates configured in the shop'), and specifies the data fields included (title, rate percentage, optional accounting chapter). It distinguishes from siblings like vat_add/vat_delete/vat_edit by being a read operation, though it doesn't explicitly contrast with other data_list_* tools beyond the VAT-specific focus.

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 this is for retrieving VAT rate information, suggesting usage when such data is needed. However, it doesn't provide explicit guidance on when to use this versus alternatives (e.g., vat_edit for modifications, or other data_list_* tools for different data types), nor does it mention any prerequisites 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?

Annotations indicate the tool is non-idempotent and non-destructive, which the description does not contradict. The description adds minimal behavioral context by noting that a title is required and listing optional fields, but it lacks details on permissions, error handling, or system impacts beyond what annotations provide.

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

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

The description is front-loaded with the core purpose and requirement, followed by a concise list of optional fields. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., bullet points) for clarity without sacrificing brevity.

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 lack of an output schema and no annotations covering permissions or side effects, the description is adequate but incomplete. It covers the basic operation and parameters but does not address what the tool returns, potential errors, or dependencies, leaving gaps for a creation tool with many parameters.

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

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

With 100% schema description coverage, the input schema fully documents all 19 parameters. The description adds marginal value by highlighting that a title is required and listing some optional fields (e.g., VAT rate, price, discount), but it does not provide additional syntax, format, or usage details beyond the schema.

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

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

The description clearly states the verb ('Add') and resource ('a new department/product category to the catalog'), making the purpose specific and unambiguous. It distinguishes this tool from sibling tools like 'dept_edit' (for editing) and 'dept_delete' (for deletion), establishing its unique role in department management.

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 by specifying that a title is required, but it does not explicitly state when to use this tool versus alternatives like 'dept_edit' or 'dept_delete'. No guidance is provided on prerequisites, such as whether department groups must exist first, leaving the context somewhat incomplete.

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

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

Annotations indicate destructiveHint=true and idempotentHint=true, which the description reinforces with 'Permanently remove'. It adds context about permanence beyond annotations, but does not detail side effects (e.g., impact on related data) or error conditions, leaving some behavioral aspects uncovered.

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, efficient sentence that front-loads the key action ('Permanently remove') and resource, with no wasted words. It effectively communicates the tool's purpose without redundancy.

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

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

For a destructive tool with one parameter and no output schema, the description covers the core action and resource adequately. However, it lacks details on prerequisites (e.g., permissions), consequences, or error handling, which would enhance completeness given the tool's critical nature.

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

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

Schema description coverage is 100%, with the parameter 'id' fully documented in the schema. The description adds no additional semantic details beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.

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

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

The description clearly states the action ('Permanently remove') and resource ('a department/category from the catalog'), and distinguishes it from siblings like dept_add and dept_edit by specifying deletion rather than creation or modification.

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 specifying 'by its ID', but does not explicitly state when to use this tool versus alternatives like dept_edit or when deletion is appropriate versus other operations. It provides basic guidance but lacks explicit exclusions or comparisons.

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

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

Annotations provide idempotentHint=true and destructiveHint=false, indicating safe, repeatable updates. The description adds valuable context: it's for existing departments only, requires ID lookup first, and fields are optional. No contradiction with annotations, but doesn't mention rate limits or auth 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?

Two sentences with zero waste: first states purpose and constraints, second provides prerequisite action. Front-loaded with essential info, appropriately sized for a 20-parameter tool.

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

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

Good for a mutation tool with annotations: purpose, guidelines, and behavioral context are covered. Lacks output schema, but description doesn't need to explain returns. Could mention auth or error handling, but annotations provide safety profile.

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

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds minimal semantics beyond schema (e.g., 'all fields are optional except the ID'), but doesn't explain parameter interactions or effects. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the verb ('Edit') and resource ('an existing department/category'), specifies it requires an ID, and distinguishes from sibling tools by mentioning data_list_departments for finding IDs. It's specific and distinguishes from dept_add and dept_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?

Explicitly states when to use ('by its ID') and when not to use (implies not for creation/deletion), provides a clear alternative (data_list_departments to find IDs first), and mentions all fields are optional except ID, guiding proper 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?

Annotations declare non-destructive and non-idempotent, which the description doesn't contradict. The description adds valuable behavioral context beyond annotations: it explains the return format (sale confirmation JSON with specific links), mentions client existence checking, and specifies payment validation requirements. However, it doesn't cover error conditions 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 is appropriately sized and front-loaded with the core purpose. Each sentence adds value: purpose, input details, usage guidance, and return format. It could be slightly more concise by combining some clauses, but overall it's well-structured without wasted words.

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

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

Given the complexity (12 parameters, nested objects) and lack of output schema, the description provides excellent completeness. It covers purpose, input semantics, usage guidelines, behavioral context, and detailed return format. The description compensates well for the missing output schema by specifying what the tool returns.

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 100% schema description coverage, the baseline is 3. The description adds meaningful context: it explains the three item types (catalog, department, free) with their required fields, clarifies the client/idClient relationship, and mentions paymentMode validation. This provides semantic understanding beyond the schema's technical specifications.

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 specific action ('Record a new order') and resource ('in the connected shop'), distinguishing it from siblings like order_edit (editing) or data_list_orders (listing). It provides concrete details about what the tool does beyond the basic title.

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

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

The description explicitly states when to use this tool vs alternatives: 'Check if the client already exists using data_list_clients and if the client exists, only specify idClient.' It also mentions prerequisites like paymentMode validation with data_list_payments_modes, providing clear operational guidance.

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

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

Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the scope of data retrieved (items, client data, etc.), which is not covered by annotations. However, it lacks details on error handling, permissions, or response format, leaving behavioral gaps.

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

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

The description is a single, efficient sentence that front-loads the purpose and details without waste. Every part ('Retrieve full order information... including items...') contributes essential information, making it appropriately sized and well-structured.

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

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

Given the tool's simplicity (one parameter, read-only annotation, no output schema), the description is largely complete for its purpose. It covers what data is retrieved but could improve by mentioning response structure or error cases, though this is mitigated by the straightforward nature of the tool.

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

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

Schema description coverage is 100%, with the parameter 'order_id' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.

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

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

The description clearly states the verb ('Retrieve') and resource ('full order information'), specifying what data is included (items, client data, payment mode, total amount). It distinguishes from sibling tools like 'data_list_orders' (which lists multiple orders) by focusing on retrieving a single order 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 implies usage context by specifying 'by its unique ID,' indicating this tool is for retrieving a specific order rather than listing multiple orders. However, it does not explicitly state when not to use it or name alternatives like 'data_list_orders' for bulk retrieval.

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

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

The description adds significant behavioral context beyond the annotations. While annotations indicate idempotentHint=true and destructiveHint=false, the description explains the complex state transitions (unvalidated quote vs validated invoice), payment recording logic, and constraints on item modifications based on order state. It also describes return values (orderID, payment link, PDF URLs).

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 efficiently structured with three sentences that each serve distinct purposes: stating the core function, explaining payment logic, and detailing constraints and returns. It's front-loaded with the main purpose and avoids redundancy, though it could be slightly more concise in the payment explanation.

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

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

For a complex mutation tool with 14 parameters and no output schema, the description provides substantial context about state transitions, constraints, and return values. It covers the critical behavioral aspects needed to use the tool correctly, though it doesn't explain all parameter interactions or edge cases.

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

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

With 100% schema description coverage, the baseline is 3, but the description adds valuable semantic context for key parameters. It explains the meaning of payment field values (-2, -1, payment method IDs) and their effect on order state, clarifies when paymentAmount should be used, and explains the items parameter constraint (only for unvalidated orders).

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 ('Modify') and resource ('an existing order by its ID'), and distinguishes it from siblings by specifying it's for editing existing orders rather than creating new ones (order_create) or listing orders (data_list_orders). It provides specific functionality details about payment states and item modifications.

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

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

The description provides explicit guidance on when to use this tool vs alternatives: 'Items can only be added or changed on unvalidated orders. Once validated, only payments can be recorded.' It also references the data_list_payments_modes tool for payment method IDs and distinguishes from order_create for new orders.

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

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

Annotations indicate non-idempotent and non-destructive behavior. Description adds 'Add' which implies creation, but doesn't elaborate on side effects or prerequisites beyond what's in schema.

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

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

Two concise sentences, front-loaded with main action, no fluff. Every sentence adds value.

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

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

Given full schema coverage and no output schema, the description adequately covers the tool's purpose, parameters, and refers to a sibling tool for listing. No gaps identified.

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 covers all parameters with descriptions. Description additionally clarifies the type enum values and meaning of cashboxLock=0, providing useful context beyond schema.

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

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

Description clearly states 'Add a new payment method to the shop', which is a specific verb-resource pair. It distinguishes from siblings like payment_mode_delete and data_list_payments_modes.

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

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

States that a title is required and enumerates optional fields. Also directs to data_list_payments_modes for listing existing methods, providing context on when to use the tool.

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

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

The description states 'permanently remove', which aligns with the destructiveHint=true annotation. It adds emphasis on irreversibility beyond the annotation. No contradictions are present.

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

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

Two efficient sentences: first states the action, second provides guidance on finding the ID. No wasted words or fluff.

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

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

With a single parameter, clear annotations, and a sibling tool for listing IDs, the description fully covers the needed context for a delete operation. No output schema is required.

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 100% coverage with a description for the 'id' parameter. The tool description only mentions 'by its ID', adding no extra meaning beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool permanently removes a payment method by ID, and distinguishes it from sibling tools like payment_mode_add. It also directs the user to data_list_payments_modes for finding the ID, reinforcing the resource context.

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

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

The description implies when to use the tool (to permanently delete a payment method) and provides a prerequisite step (find ID via data_list_payments_modes). It lacks explicit exclusions or alternatives, but for a delete operation, the context is clear.

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

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

Annotations indicate idempotentHint=false and destructiveHint=false, which the description doesn't contradict. The description adds value by specifying the required title and listing optional fields, but lacks details on permissions, rate limits, or error handling. With annotations covering basic safety, this earns a baseline score for minimal added 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 front-loaded with the core purpose and requirement, followed by a concise list of optional fields. It avoids redundancy and stays focused, though the phrase 'and many more' could be slightly vague, but overall it's efficient.

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

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

For a tool with 29 parameters, 100% schema coverage, and no output schema, the description adequately covers the basic operation and key fields. However, it lacks details on behavioral aspects like response format or error cases, making it minimally complete but with room for improvement given the complexity.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description lists key optional fields like price, department, and VAT rate, but doesn't add meaning beyond what the schema provides (e.g., explaining relationships or constraints). This meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Add a new item/article') and resource ('to the shop catalog'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'plu_edit' or 'plu_delete' beyond the verb 'Add,' which slightly limits its distinction.

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 that a title is required, but provides no guidance on when to use this tool versus alternatives like 'plu_edit' for updates or 'plu_delete' for removal. There's no mention of prerequisites, context, or exclusions, leaving usage decisions ambiguous.

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

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

Annotations provide destructiveHint=true and idempotentHint=true, indicating a safe but irreversible operation. The description adds value by emphasizing 'permanently remove,' reinforcing the destructive nature beyond annotations. However, it does not disclose additional behavioral traits like error handling 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?

The description is a single, front-loaded sentence with zero waste—every word contributes to understanding the tool's purpose and key constraint. It is appropriately sized for a simple deletion tool.

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

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

For a destructive tool with one parameter and good annotations, the description is mostly complete. It covers the core action and permanence, but lacks output details (no schema) and could benefit from more context on error cases or confirmation steps, though annotations help mitigate gaps.

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

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

Schema description coverage is 100%, with the parameter 'id' fully documented in the schema. The description adds minimal semantics by specifying 'by its ID' but does not provide extra details like format constraints or examples beyond what the schema already covers.

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 specific action ('permanently remove') and resource ('item/article from the catalog'), distinguishing it from siblings like plu_add or plu_edit. It explicitly mentions deletion by ID, making the purpose unambiguous and distinct.

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 specifying deletion 'by its ID,' but it does not explicitly state when to use this tool versus alternatives (e.g., no mention of plu_edit for updates or account_delete for other resources). It provides clear prerequisites (need an ID) but lacks explicit exclusions or sibling comparisons.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, which the description doesn't contradict. The description adds context about optional fields and ID requirement, but lacks details on permissions, rate limits, or mutation effects. With annotations covering safety, it adds moderate value without rich behavioral disclosure.

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

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

The description is two sentences, front-loaded with the core purpose and followed by essential usage guidance. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 30 parameters and no output schema, the description is adequate but minimal. Annotations cover idempotency and non-destructiveness, but more context on return values or error handling would enhance completeness. It meets minimum viability given the schema's thoroughness.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds that 'All fields are optional except the ID,' clarifying the update semantics, but doesn't provide additional meaning beyond what the schema already specifies for each parameter.

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 ('Edit an existing item/article') and resource ('in the catalog'), specifying it requires an ID. It distinguishes from siblings like 'plu_add' (create) and 'plu_delete' (delete) by focusing on modification, though it doesn't explicitly contrast with other edit tools like 'client_edit' or 'dept_edit'.

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

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

It provides explicit guidance on when to use ('Edit an existing item/article') and a prerequisite ('Use data_list_products to find the article ID first'), which helps differentiate from creation tools. However, it doesn't specify when not to use this tool or mention alternatives for similar operations (e.g., 'client_edit' for different resources).

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

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

Annotations declare readOnlyHint=true, and the description aligns by describing a download operation without implying mutation. It adds valuable context beyond annotations: specifies the report is synthetic HTML, details the return content (revenue, orders, breakdowns), and explains the period logic, which isn't covered by annotations alone.

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

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

Two sentences are front-loaded with the core purpose, followed by detailed period logic and return content. Every sentence earns its place by providing essential guidance without redundancy, making it efficient and well-structured.

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

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

Given the tool's moderate complexity, rich annotations (readOnlyHint), and full schema coverage, the description is complete. It explains behavior, parameter usage, and output details (HTML summary with specific metrics), compensating for the lack of an output schema adequately.

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

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

With 100% schema description coverage, the schema already documents parameters well. The description adds meaningful semantics by explaining how parameter combinations affect period selection (e.g., omit all for yesterday, y only for full-year), which clarifies usage beyond the schema's technical bounds.

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 specific action ('Download a synthetic HTML sales report') and resource ('for a given period'), distinguishing it from sibling tools like data_list_orders or order_detail by focusing on report generation rather than raw data listing or order 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?

It explicitly defines when to use this tool based on date parameters: omit all fields for yesterday's report, provide y only for full-year, y+m for full-month, and y+m+d for a specific day. This gives clear context for parameter combinations without needing to reference alternatives.

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

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

Annotations indicate idempotentHint=false and destructiveHint=false, which the description does not contradict. The description adds value by specifying required and optional fields, but does not disclose additional behavioral traits like permissions needed, rate limits, or what happens on duplicate entries. With annotations covering basic safety, it provides some context but not rich 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?

The description is front-loaded with the core purpose, followed by essential details on required and optional fields in a single, efficient sentence. Every part earns its place with no redundant information, making it highly concise and well-structured for quick understanding.

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 moderate complexity (creation operation with 4 parameters), 100% schema coverage, and annotations providing safety hints, the description is mostly complete. It covers purpose and field requirements adequately. However, without an output schema, it does not describe return values or success/error responses, leaving a minor gap in completeness.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by listing required and optional fields, but does not provide additional meaning beyond what the schema specifies, such as format examples or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Add a new VAT rate') and resource ('to the shop configuration'), distinguishing it from sibling tools like vat_edit and vat_delete. It explicitly mentions what is being created, making the purpose unambiguous and distinct from related operations.

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

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

The description provides clear context for when to use this tool (adding a new VAT rate) and implies usage through required fields, but does not explicitly state when not to use it or name alternatives like vat_edit for modifications. It distinguishes from siblings by function but lacks explicit exclusions or named alternatives.

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

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

Annotations provide idempotentHint=true and destructiveHint=true, indicating safe retry behavior and destructive action. The description adds value by specifying 'Permanently remove,' reinforcing the irreversible nature beyond annotations, though it lacks details on permissions or error handling.

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

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

The description is a single, front-loaded sentence with zero waste—every word contributes to clarity. It efficiently communicates the tool's purpose and key constraint ('permanently') without unnecessary elaboration.

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 destructive nature (annotations cover this), one parameter with full schema coverage, and no output schema, the description is reasonably complete. It could improve by mentioning side effects or confirmation steps, but it adequately supports tool selection and invocation.

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

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

Schema description coverage is 100%, with the parameter 'id' fully documented in the schema. The description adds no additional semantic details beyond implying the ID is for a VAT rate, aligning with the baseline score when schema coverage is high.

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 specific action ('Permanently remove') and resource ('a VAT rate from the shop configuration by its ID'), distinguishing it from sibling tools like vat_add and vat_edit. It precisely conveys the tool's function without ambiguity.

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 by specifying 'by its ID' and context ('from the shop configuration'), but does not explicitly state when to use this tool versus alternatives like vat_edit or when deletion is appropriate. No exclusions or prerequisites 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?

The description adds valuable behavioral context beyond annotations: it clarifies that all fields except ID are optional (partial updates allowed) and that it modifies existing records. Annotations already indicate idempotentHint=true and destructiveHint=false, so the description doesn't contradict them but provides practical implementation details about field requirements.

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

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

The description is perfectly concise with two sentences that each earn their place: the first states the core purpose, the second clarifies the parameter behavior. It's front-loaded with the essential information and contains no redundant or 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?

For a mutation tool with good annotations (idempotent, non-destructive) and complete schema coverage, the description provides adequate context. It explains the editing operation and field requirements clearly. The main gap is lack of output information (no output schema), but the description compensates reasonably given the tool's moderate 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?

With 100% schema description coverage, the input schema already documents all 5 parameters thoroughly. The description adds marginal value by emphasizing that only 'id' is required and other fields are optional, but doesn't provide additional semantic context beyond what's in the 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 specific action ('Modify an existing VAT rate'), identifies the resource ('VAT rate'), and specifies the required identifier ('by its ID'). It distinguishes from sibling tools like 'vat_add' (create) and 'vat_delete' (remove) by focusing on editing existing records.

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

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

The description provides clear context for when to use this tool ('Modify an existing VAT rate'), but doesn't explicitly state when not to use it or name alternatives. It implies usage for updates rather than creation or deletion, but lacks explicit exclusions or comparisons to siblings like 'vat_add' or 'vat_delete'.

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