Vidé Vita

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

Description discloses side effect (writes a pending order) and need for authentication token. While annotations say destructiveHint=false (so not destructive), it's a write operation; description adds the crucial 'puts a row in the shop's books' context. Could mention that idempotency is not guaranteed, but annotations already say idempotentHint=false. Strong coverage of behavioral traits not in 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?

Two sentences, front-loaded with purpose, second sentence gives the critical side-effect guidance and alternative tool. Zero filler.

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

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

Description covers purpose, side effect, token requirement, and alternative. No output schema, but return is a pay page URL - description implies that. Could be slightly more explicit about what 'pay page' returns, but close to complete.

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

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

Schema covers 50% of parameters (items required, email described) and description mentions 'token' without a schema parameter (likely contextual token). No extra parameter guidance beyond what schema provides. Not harmful, but doesn't add much 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?

Clear verb (create) + resource (payment link) + effect ('writes a real pending order', 'returns its pay page'). Distinct from start_checkout which is named as the alternative for ordinary purchases.

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 ('for an ordinary purchase use start_checkout instead') and warns about side effect (requires token because it writes to the books). No other guidance needed.

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 only that the email must be attached to the order, but does not clarify side effects, authorization requirements, error behavior, or what the response will contain. Annotations are not helpful here because they are all false/neutral, so the description still carries the full burden and is insufficient.

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 only two short sentences and contains no filler. Both sentences earn their place: one states purpose and the other states required inputs. It is easy to parse and front-loads the key 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 two-parameter status lookup, the description might be minimally usable, but it still lacks clarity about what status information is returned, what errors or indications apply, and how this relates to other order-facing tools like start_checkout or create_payment_link. Since there is no output schema, more context would be needed.

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

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

Schema coverage is 0%, meaning the description must clarify the parameters. It does partly compensate by mapping 'order number' to order_id and clarifying that email means 'the email on it,' i.e., the email associated with the order. This adds useful context beyond the raw schema.

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

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

The description clearly indicates that the tool returns an order's current position/status, and the resource (order) is identifiable. It is distinguishable from sibling tools like get_product and get_reviews, though the phrasing is informal and could more explicitly say 'returns order status.'

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

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

The description gives an important usage precondition: the caller must provide the order number and the email used on the order. However, it does not explicitly explain when to prefer this tool over alternatives, when not to use it, or what to do if the email/order_id combination is invalid.

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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds value by explaining what specific product information is returned, which goes beyond bare read-only hints and helps the agent understand the tool's scope.

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 that conveys the tool's purpose and output contents without restating the name or adding filler. Every part contributes to understanding the tool.

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

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

The tool has a simple one-parameter schema and rich annotations, and the description gives enough behavioral and content context for an agent to select and invoke it appropriately. There is no output schema, but the described fields ('label amounts', 'how to take', 'price', 'pictures') provide a reasonable preview of the response.

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

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

The schema covers 100% of the parameter description, including an example value, so the description does not need to add much. It does loosely connect slug to retrieving a single product, but adds no additional semantic detail 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 identifies the tool as retrieving detailed store-provided information about a single product, explicitly naming key content areas such as amounts, usage directions, price, and images. It also distinguishes it from siblings like list_products and search_products by emphasizing 'one product.'

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

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

The description makes it clear this is for getting full product details for one item, which implicitly signals when a user should choose it over listing or searching. It does not explicitly name alternatives or state when not to use it, but the single-product framing is sufficient 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 already declare readOnlyHint, idempotentHint, and non-destructive behavior, so safety is well covered. The description adds scope information (one product vs whole shop) but does not elaborate on pagination, sorting, or whether empty/missing review data is handled.

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

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

The description is a single concise sentence with no fluff. Every word contributes meaning, and the main distinction—single product vs whole shop—is front-loaded.

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

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

Given the tool's simplicity, one optional parameter, and rich safety annotations, the description is largely complete for purpose and selection. However, since there is no output schema, a bit more detail about what the returned reviews contain (text, rating, timestamps) would improve it.

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

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

The schema only labels the slug as 'optional', but the description clarifies that it effectively 'scopes the query to one product, otherwise returns the whole shop'. This adds real meaning to the only parameter, going beyond the schema description.

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

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

The description clearly identifies the resource as customer reviews and communicates the retrieval scope: by product or across the whole shop. This distinguishes get_reviews from sibling tools like get_product, list_products, get_order_status, and create_payment_link.

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 phrase 'for one product or the whole shop' provides clear context for how the tool is used: optionally target a product via slug, or omit it for shop-wide reviews. It does not explicitly list exclusions or name alternative tools, but the usage 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety profile is known. The description adds that it returns price, stock, and summary for every sale product, which is useful but does not disclose behaviors like pagination, rate limits, or data freshness. Since annotations cover the core, score is moderate.

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, no fluff, clear and structured: what it returns (products), scope (on sale), and fields (price, stock, summary).

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?

Complete for a read-only list-all tool with no parameters and good annotations. Could mention pagination but likely unnecessary. Distinguishable from siblings.

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?

Tool has zero parameterscars; schema covers all 0 parameters with no ambiguity. No parameter definition needed.

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

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

The description clearly states the tool lists every product on sale, with specific attributes (price, stock, one-line summary). This differentiates it from siblings like get_product (single product) and search_products (filtered), making its purpose 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: call this to get a full catalog of products on sale. It doesn't explicitly mention alternatives like search_products for filtered queries or get_product for a single item, so it lacks explicit when-to-use vs. not guidance, but the context is clear.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context about language support and query semantics, but it does not disclose return format, ranking, or pagination behavior. This is acceptable given the annotations but not richly transparent.

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

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

The description is a single, front-loaded sentence with no filler. Every clause adds value: the search behavior, supported languages, and example query intents.

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 one-parameter search tool with strong annotations, the description is nearly complete. It does not explicitly describe the return value, but the tool name and search framing make it clear that matching products are returned. A brief note on result ordering or limits would make it fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by explaining that the query should be a customer-style phrase in Thai or English and may reference an ingredient, concern, or brand. This adds meaningful guidance beyond the bare 'query' string field.

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 searches the shop using natural-language customer-style queries, with specific examples (ingredient, concern, brand). This distinguishes it from sibling tools like list_products or get_product, which imply structured listing or exact lookup.

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

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

The description gives clear context for when to use the tool: when a search should be phrased as a customer would ask, in Thai or English. It does not explicitly name alternatives or exclusions, but the natural-language framing is enough to differentiate from the more structured sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about the content (delivery, payment, returns) but does not disclose any additional behavioral traits such as response format or potential variability. 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 a single, concise sentence that covers the key aspects of the tool. It is front-loaded and contains no unnecessary words, making it highly efficient.

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

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

Given the tool has no parameters, no output schema, and simple annotations, the description is sufficient to understand its purpose and scope. It covers the main content areas (shop, operator, delivery, payment, returns) and is complete for a simple informational tool.

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

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

The tool has zero parameters, and schema coverage is 100% (vacuously). The description adds meaning by explaining what information the tool returns, which is useful since there is no output schema. With no parameters, the description's role is to clarify the tool's purpose, which it does adequately.

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 provides information about the shop, its operator, and policies on delivery, payment, and returns. It is specific enough to distinguish it from sibling tools like get_product or get_order_status, though it could be more explicit about being a read-only overview.

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 tool is for general shop information, but it does not explicitly state when to use it versus alternatives. Given the sibling tools, it is clear this is for high-level shop details, but no explicit guidance 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?

The annotations already provide readOnlyHint/idempotentHint/destructiveHint, and the description adds useful behavioral context: nothing is charged, no account is needed, and the customer pays as a guest. This meaningfully clarifies the tool's side-effect profile beyond the annotations, though it does not discuss things like link expiry or checkout session 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 three well-organized sentences: action and output, cost/account behavior, and usage guidance. Every sentence contributes useful information and there is no unnecessary repetition of the tool name or schema details.

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 this is a one-parameter tool with no output schema, the description is largely complete: it covers what happens, what the tool returns, the guest-payment behavior, and the intended use case. The main missing piece is parameter semantics around the item slug, but overall the definition is adequate for inspection and safe 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 0%, so the description needed to compensate, but it only says 'these items' without explaining what `slug` means, where valid slugs come from, whether quantity is required, or how the items array should be formed. The schema shows the shape, but the description adds very little parameter-level meaning beyond the property name.

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

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

The description states a specific action and output: 'Put these items in the shop's cart and hand back the link that opens checkout.' This clearly distinguishes start_checkout from the sibling tools, which are mostly read/search/payment-link tools, and makes the ordinary-purchase checkout purpose explicit.

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

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

The description gives a clear usage context: 'Use this for an ordinary purchase' and clarifies that it does not charge or require an account. It does not explicitly name sibling alternatives like create_payment_link or state when not to use it, so it stops short of full exclusion 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds useful context about the type of data (assistant queries and failures) but doesn't disclose any other behavioral traits like rate limits or data retention, which is acceptable given the simple nature.

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, concise sentence that front-loads the core purpose. It is not bloated, though it could possibly incorporate more detail without sacrificing brevity. It earns points for efficiency but could be slightly more informative.

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

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

The tool has no output schema and only one optional parameter. The description gives a high-level summary but lacks details on the parameter's purpose and the expected return format. Since there is no output schema to rely on, the description carries the burden, and it fails to compensate for the missing parameter explanation and output shape.

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

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

Schema description coverage is 0% and the description does not explain the 'days' parameter. While the name suggests a time range, the absence of any elaboration means agents must infer its meaning. The description should at least mention that 'days' specifies the reporting window.

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 provides a report on what assistants have been asking and which questions failed, making its purpose specific and distinct from sibling tools like order status or product search. It lacks an explicit verb like 'retrieve' but conveys the function effectively.

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 viewing usage statistics, but it doesn't explicitly state when to use it or provide any exclusions. There are no competing sibling tools for this purpose, so the lack of alternative guidance is acceptable, but explicit context would improve clarity.

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