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

No annotations are provided, so the description carries the full burden. It discloses that the price is always 0, requires authentication, has a default flashDealId, and includes a clear error-handling flow (call get_flash_deal_status on eligibility failure to diagnose). It doesn't describe the success return value, but that is a minor gap for a cart-add tool.

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

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

The description is a single paragraph with several distinct instructions, all relevant and front-loaded with the primary purpose. It is slightly verbose but every sentence earns its place, so it remains 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?

Covers purpose, alternatives, parameter sourcing, error handling, and authentication. The only missing piece is a description of the success response, but given the tool's simplicity and lack of output schema, this is a minor omission.

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

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

Schema coverage is 100% with each parameter described. The description adds extra context beyond the schema by specifying that productId comes from get_flash_deals and that flashDealId defaults to 11732, reinforcing the 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 explicitly states 'Add a Mega Flash Deal product to the cart for free' with a specific verb and resource, and clearly distinguishes from the sibling add_to_cart by saying to use this instead for flash deal items.

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

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

Provides explicit when-to-use guidance: 'Use this instead of add_to_cart for flash deal items' and when not to use get_flash_deal_status: 'Do NOT call get_flash_deal_status before every add — only use it to explain a failure.' This clearly maps alternatives and 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?

With no annotations, the description carries the burden and does well by disclosing that authentication is required and that productId/price must be sourced from search/list products. It also clarifies its behavioral role (add vs. increase). However, it doesn't reveal potential side effects (e.g., failure behavior) or whether quantity is absolute/incremental beyond the schema's 'Target quantity to set'.

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

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

The description is concise and well-structured: the primary action is stated first, followed by usage boundaries, alternatives, auth, and data sourcing. Every sentence serves a 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?

The description is complete for a moderately complex tool: it covers purpose, alternatives, authentication, and parameter provenance. It doesn't mention error handling or return values, but there is no output schema, and these are not essential for selecting/invoking the tool correctly in most 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by telling the agent where to obtain productId and price ('Get productId and price from search_products or list_products'), which is not in the schema. It also reinforces the quantity parameter's intent with the 'bumping qty' example, though the schema already describes it as a target quantity.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Add a NEW product to the basket or INCREASE the quantity of an existing product.' It also explicitly distinguishes itself from sibling tools by naming remove_from_cart and add_flash_deal_to_cart for alternative use cases.

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 usage boundaries: 'Use this only when the quantity is going UP' and gives concrete examples. It also names the exact alternatives for decreasing/deleting (remove_from_cart) and flash deals (add_flash_deal_to_cart), fulfilling the when/when-not 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 states the effect of the tool (clearing tokens, logging out) clearly. Since no annotations are present, the description carries the burden of disclosing behavior. It does not explain whether the clearing is local-only or server-side, but the core side effect is explicit.

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

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

A single, concise sentence effectively communicates the purpose without extraneous detail. All words contribute 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?

For a simple logout operation with no parameters and no output schema, this description is appropriately complete. It explains both the mechanism (clearing tokens) and the outcome (logging out).

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 the schema confirms an empty object. Per the rubric, a description for a parameterless tool earns a baseline of 4 since there are no parameter semantics to clarify.

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

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

The description clearly states the tool's function: clearing stored access and refresh tokens to log out. It uses a specific verb ('Clear') and resource ('access and refresh tokens'), making it distinguishable from sibling auth tools like auth_status and auth_verify_otp.

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 or how it relates to other auth tools. It doesn't mention prerequisites, expected session state, or alternatives, leaving usage context implicit.

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

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

No annotations are provided, so the description carries the burden. It discloses a significant privacy behavior (data goes directly to Milkbasket, not through AI), which is valuable. However, it does not mention side effects like SMS delivery, 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 with no fluff: purpose, usage order, and an important user reassurance. The privacy note earns its place as an actionable agent instruction, and the description is 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 single-param tool, the description covers purpose, sequencing, and a key privacy concern. It does not explain the response format or failure scenarios, but given the simplicity and the schema coverage, it is fairly complete.

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

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

The schema covers the phone parameter 100% with a clear description, min/max lengths, and an example. The description adds no extra param details, but with full schema coverage the 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 states a specific verb and resource: 'Request a one-time password (OTP) to be sent to the given phone number.' It also distinguishes from siblings by saying 'Call this first to initiate login,' which clarifies its role relative to auth_verify_otp and auth_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 clear when-to-use guidance: 'Call this first to initiate login.' It does not explicitly name alternatives like auth_verify_otp, but the context makes the sequential usage 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states the tool reports whether the session is authenticated and its expiry time, covering the core behavioral outputs. It does not detail edge cases or response formats, preventing a higher score.

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 directly states the tool's purpose without waste. It is front-loaded with the verb and includes only essential additional detail about expiry.

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 (no parameters, no output schema), the description sufficiently covers the functional aspects. It tells the agent what to expect (authentication status and expiry), though it does not specify the exact return format. This is adequate for a simple status check.

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 zero parameters, so the description is not required to explain parameter semantics. The baseline for 0 parameters is 4, and the description does not need to add anything beyond the schema.

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

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

The description uses the specific verb "Check" and identifies the resource as the current session's authentication state and expiry. This clearly distinguishes it from sibling auth tools like auth_request_otp and auth_logout, which perform actions rather than inspect 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 provides clear context that this tool is for checking authentication status, implying its appropriate use case. However, it does not explicitly reference alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It reveals security-relevant behavior: the OTP is never stored or seen by any AI/third party, and tokens are stored securely in the OS keychain. This adds useful context beyond the simple 'verify OTP' action, though it does not cover failure modes or token expiration.

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 compact and front-loaded with the core purpose. The lengthy quoted reassurance message is essential safety information and not wasted text. Every sentence earns its place, and the 'IMPORTANT' marker effectively highlights critical 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 login verification tool with no output schema and no annotations, the description covers the essential flow: verifying the OTP, reassuring the user about security, and disclosing token storage. It lacks details on error handling or OTP expiry, but it provides enough context for an agent to invoke it correctly in the login sequence.

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 already covers 100% of the parameters with clear descriptions (e.g., 'The same phone number used in auth_request_otp'). The description adds no additional meaning about the parameters themselves, 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 opens with a specific action: 'Verify the OTP received on the phone number to complete login.' This clearly states the tool's verb (verify), resource (OTP), and purpose (complete login), distinguishing it from siblings like auth_request_otp and auth_logout.

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 instructs when to use the tool ('to complete login') and provides a mandatory user-facing reassurance message to deliver before asking for the OTP. It does not explicitly name alternatives or state when not to use it, but the context of login completion 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?

With no annotations provided, the description carries the full burden. It discloses authentication requirements and what data is returned, which is helpful. It does not mention error handling or side effects, but for a read-only snapshot the description is reasonably 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 concise and well-structured: it opens with the core function, then provides usage guidance, an alternative, and a final auth requirement. Every sentence earns its place with no redundancy.

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

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

For a simple parameterless tool, the description fully covers its purpose, contents, when to use it, alternatives, and authentication. It is complete enough for an agent to select and invoke correctly without additional 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?

The tool has zero parameters, and schema coverage is 100% (empty schema). Baseline for 0 params is 4. The description adds context about return values, but no parameter semantics are 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's function with a specific verb ('Fetch') and resource ('lightweight snapshot of the current cart'), listing exact contents (product IDs, quantities, unit prices, bill summary) and distinguishing it from get_extended_basket.

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 this tool (quick cart check, verifying item in cart, item count, basic total) and provides a direct alternative (get_extended_basket) for full checkout view. This is excellent guidance for an AI agent.

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

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

With no annotations, the description carries the full burden. It discloses that authentication is required and details the exact data returned (products, prices, discounts, fees, taxes, cashback, final payable). It does not mention side effects or error behavior, but as a fetch tool, the core behavior is well covered. Slightly more context could be provided (e.g., whether it modifies anything), but it is still informative.

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 longer than minimal but every sentence contributes: the core fetch action, the detailed return fields, specific use cases, and the pointer to get_basket. It is front-loaded with the main purpose and stays on-topic, though a few redundant phrases (e.g., 'COMPLETE' and 'EXTENDED') could be trimmed. Overall 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 no output schema and no annotations, the description adequately covers return content, use cases, and required authentication. It also differentiates from the sibling tool, making the context complete for an agent to choose and invoke 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 tool has zero parameters, so per the rubric the baseline is 4. The description adds no parameter-specific semantics, which is fine since there are none. It does clarify that the tool returns full details without needing inputs.

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 fetches the full basket with complete product details and an extended bill breakdown, explicitly distinguishing it from the lighter get_basket sibling. The verb 'Fetch' plus resource 'full basket (cart)' is specific and not a 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?

It explicitly lists when to use this tool (detailed cart view, checkout screen, showing product names/discounts, complete bill breakdown) and when to use the alternative (get_basket for quick checks like item count or basic total). This is model guidance with clear 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?

With no annotations provided, the description carries the burden and partly compensates: it discloses authentication needs, pagination behavior, default listId, and the return schema. It does not mention error behavior or rate limits, but for a read-only fetch tool, this is reasonably 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 three sentences, front-loaded with the core purpose, then return details, then authentication and the critical cart-add warning. Every sentence earns its place with no filler 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 simple paginated read tool, the description covers the essential context: what it fetches, what it returns, authentication, and a critical cross-tool caveat. It does not mention sorting or failure modes, but the low complexity and good schema coverage make it sufficiently complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema, only reinforcing that listId '157975' is the flash deals collection. No parameter-level details are explained beyond what the schema already contains.

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

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

The description uses a specific verb 'Fetch' and a clear resource 'today's Mega Flash Deal products', explicitly distinguishing it from sibling tools like list_products and search_products. It also lists the output fields (name, weight, MRP, selling price, discount %, stock status), leaving no ambiguity about what the tool does.

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

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

The description states a prerequisite ('Requires authentication') and provides explicit guidance for a related action: 'To add any product from this list to the cart, always use add_flash_deal_to_cart — never use add_to_cart for flash deal items.' It doesn't contrast with list_products for fetching non-flash deals, but the warning about the cart is a clear when-not/alternative.

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

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

With no annotations provided, the description carries the burden. It discloses the return contents (deal terms, basket value vs. minimum, claimed vs. max free items, deal timing, human-readable status), the authentication requirement, and the diagnostic use case. This goes beyond a simple read-only hint.

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, front-loaded with the purpose, and every sentence adds value: description, return details, usage context, and defaults. No fluff or redundant information.

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

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

Despite no output schema, the description thoroughly explains what will be returned, the scenario for using the tool, and the authentication prerequisite. It provides sufficient information for an agent to invoke and interpret the result.

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 already fully documents the single 'id' parameter with type, default, and description. The description merely repeats the default deal ID (11732), adding no additional semantic meaning beyond the schema's 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 it 'Get[s] the status and eligibility details of a Mega Flash Deal,' with a specific verb and resource. It also distinguishes from sibling tools by focusing on a single deal's status and diagnosis rather than listing deals or adding to cart.

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 says 'Use this to check why a flash deal item could not be added to cart,' providing a concrete scenario. It also notes the authentication requirement, though it does not name alternative tools or describe when not to use it.

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

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

As there are no annotations, the description must carry the burden. 'Fetch' indicates a read operation, and the mention of listId being used with list_products is a useful behavioral context. However, it doesn't specify authentication requirements, response format, or any side-effect guarantees, so it only partially discloses behavior.

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

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

The description is two concise sentences, front-loaded with the verb and resource. The second sentence provides actionable information about the listId-to-list_products workflow without redundancy.

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

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

For a simple, parameterless fetch tool with no output schema, the description provides the essential context: what it returns (hero collections), and how to use the returned listId to further browse products. It lacks details about return fields beyond listId and possible auth, but for the primary use case it is sufficiently complete.

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

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

The tool has zero parameters, so the description is not required to explain parameter semantics. The baseline of 4 applies because there's no parameter burden, and the description doesn't attempt to add unnecessary param information.

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

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

The description uses the specific verb 'Fetch' and resource 'homepage hero collections', clearly distinguishing it from siblings like get_flash_deals or list_products. It also provides a functional link to list_products via listId, making its role 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 a clear usage pattern: first retrieve hero collections, then pass the listId to list_products to browse products. It doesn't explicitly name exclusions or alternative tools for when not to use it, but the context is clear enough to guide an agent.

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

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

With no annotations, the description carries the full burden. It discloses the authentication requirement and lists the returned data fields, but it does not explicitly state read-only behavior or describe the outcome if the user is not authenticated. The verb 'Fetch' implies read-only, but additional transparency about error handling or side effects would strengthen it.

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 verb and resource. Every word contributes value, with no filler or repetition of the tool name.

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 parameterless tool with no output schema, the description covers the essential return fields (name, email, address, delivery info, wallet balance) and the auth prerequisite. It does not address error behavior or alternative tools, but the core functionality is well-specified for a simple getter.

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 zero parameters, so the description has no parameter semantics to clarify. Per calibration, 0 parameters gives a baseline of 4; the description adds no unnecessary parameter detail and focuses on the tool's purpose.

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

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

The description clearly states 'Fetch the logged-in user's profile (name, email, address, delivery info) and wallet balance.' This is a specific verb+resource with a clear scope, and it distinguishes itself from sibling tools such as get_wallet_balance (wallet-only) and auth_status (session check) by combining profile and wallet data.

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

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

The description mentions 'Requires authentication' as a prerequisite, which gives some usage context. However, it does not explicitly state when to prefer this tool over alternatives like get_wallet_balance for wallet-only needs or auth_status for authentication checks. The guidance is implied but lacks explicit when/when-not or alternative naming.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It explicitly states 'Requires authentication' and uses the verb 'Fetch' to imply a read-only operation. It also details what the balance includes (main, food, cashback credits), adding useful context. It could be more explicit about having no side effects, but 'Fetch' is a strong read signal.

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 with no fluff, front-loading the primary action and resource. Every word contributes value, such as 'logged-in' and 'Requires authentication.'

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

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

For a simple tool with no parameters and no output schema, the description is complete. It tells what the tool returns (wallet balance with categories), who it applies to (logged-in user), and the prerequisite (authentication). No additional context is 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?

The tool has zero parameters, and the schema is empty. The description doesn't need to explain parameters, and the baseline for 0 params is 4. It adds no parameter-related meaning, but none is 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 'Fetch the logged-in user's wallet balance including main credits, food credits, and cashback credits' clearly states the action (fetch) and the resource (wallet balance) with specific detail. It distinguishes itself from sibling tools like auth_status and get_basket by focusing on wallet balance for the logged-in user.

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 usage context by specifying it applies to the logged-in user and requires authentication. It does not explicitly name alternatives, but no sibling tool serves the same function (wallet balance), so the guidance is sufficient.

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

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

No annotations are provided, so the description carries the burden. It discloses that authentication is required and implies a read-only operation ("List"). It also mentions the prerequisite of obtaining the listId from get_hero_collections. However, it does not discuss rate limits or error handling, which are minor for a read operation. The added context goes beyond a generic 'list' description, so a 4 is well-deserved.

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 action, then supplemented by pagination/filtering and auth requirements. Every sentence adds value with no redundancy or verbosity.

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

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

For a list tool with no output schema, the description provides the essential context: how to identify the collection, what features are supported, and authentication needs. It could explicitly state the return shape (e.g., array of products), but given that it is a list operation and the schema covers pagination parameters, the description is adequately complete. The missing return format is a minor gap.

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

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

The input schema already provides full descriptions for all four parameters, including defaults and ranges (100% coverage). The description adds the important provenance that listId comes from get_hero_collections, which is also in the schema but reinforces the relationship. Since the schema handles the heavy lifting, a baseline of 3 is justified.

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 products from a specific collection using a listId, which is a specific verb+resource+scope. It also distinguishes from sibling tools like search_products by referencing collection-based browsing and explicitly ties the listId to get_hero_collections.

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: use this when you have a listId from get_hero_collections, and it supports pagination and in-stock filtering. It does not explicitly name alternatives like search_products, but the reference to collection-specific listing implies when to use it. This is clear context without explicit exclusions or alternatives, so a 4 is appropriate.

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

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

With no annotations provided, the description carries the full burden. It discloses authentication requirements and the special meaning of quantity=0 for complete removal. It does not mention return format or error cases, but for a simple mutation, the key behavioral aspects are covered.

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), front-loaded with the core purpose, and every sentence contributes: usage condition, alternative tool, auth requirement, and parameter sourcing. No redundant or irrelevant text.

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

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

Despite lacking an output schema and annotations, the description covers purpose, usage, auth, and parameter sourcing. It could have mentioned return behavior, but given the tool's simplicity and the availability of get_basket for checking results, the description is sufficiently complete for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by emphasizing the zero-quantity removal behavior and by directing the agent to source productId and price from specific basket-getting tools, which goes beyond the schema's field 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 tool's action: 'DECREASE the quantity of a product in the basket or DELETE it entirely.' This is a specific verb and resource, and it explicitly contrasts with the sibling tool add_to_cart, making it easy to distinguish.

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?

Usage is explicitly conditioned on quantity change direction: 'Use this when the quantity is going DOWN.' It also names the alternative for increasing/adding: 'To ADD a new product or INCREASE quantity, use add_to_cart instead.' Additionally, it tells where to obtain required parameters: 'Get productId and price from get_basket or get_extended_basket.'

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions 'Supports pagination' and 'Requires authentication,' which add useful context about response pagination and access prerequisites. However, it doesn't describe return format, ordering, or read-only status beyond what the name implies.

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 brief sentences that front-load the core function ('Search for products') and add only essential modifiers ('by name or keyword,' 'across the Milkbasket catalog,' 'Supports pagination,' 'Requires authentication'). No fluff 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?

With no output schema, the description provides enough context for a simple search tool: it states the purpose, pagination support, and auth requirement. It doesn't explicitly describe the response structure, but 'search for products' implies a product list, and the schema fully documents all parameters, making the description reasonably complete for this low-complexity tool.

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

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

The input schema covers all three parameters with descriptions (searchText, page, limit), achieving 100% schema coverage. The description adds no additional parameter-level detail beyond what the schema already provides, so the 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 'Search for products by name or keyword across the Milkbasket catalog' – a specific verb and resource. It distinguishes from siblings like list_products by emphasizing keyword-based search, making it clear this is a search-tool rather than a list-all-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 implies usage for finding products by name/keyword but does not explicitly compare to alternatives such as list_products. No exclusions or 'when to use' guidance is provided, so usage is inferred rather than explicitly stated.

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