Server Quality Checklist

Tool Scores

• lufa_get_nutritional_factsB
  3.4/5.0
  Behavior3/5

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

  The description gives some transparency by listing return contents (calories, macronutrients, ingredient list) and uses 'Retrieve' implying a read-only operation. However, no annotations are present, and the description does not address potential errors, authentication requirements, or behavior when product_id is invalid, leaving gaps.

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

  Conciseness5/5

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

  The description is extremely concise and well-structured: a one-line purpose, a one-line return summary, and a clear parameter definition. No unnecessary words or repetition.

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

  Completeness4/5

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

  For a simple 1-parameter read tool with no output schema, the description is largely complete: it states what the tool returns and what the parameter is. It could be improved by clarifying distinction from get_product_details, but overall it is sufficient for basic invocation.

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

  Parameters3/5

  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 defines product_id as 'Product ID to look up', which clarifies the parameter's meaning but lacks format details or how to obtain valid IDs. This is adequate but minimal.

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

  Purpose4/5

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

  The description clearly states the tool retrieves nutritional information panel for a product, listing specific return values (calories, macronutrients, ingredient list). It is unambiguous but does not explicitly differentiate from sibling tools like lufa_get_product_details, which may also return nutrition data.

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

  Usage Guidelines2/5

  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. The description simply states what it does, with no mention of appropriate contexts, exclusions, or how it differs from similar tools like get_product_details or search_products.

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

• lufa_logoutA
  4.2/5.0
  Behavior4/5

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

  Description explicitly discloses a destructive side effect: 'erase the saved session from disk'. With no annotations provided, the description carries the burden and meets it by revealing this behavioral trait.

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

  Conciseness5/5

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

  Single sentence that is direct and front-loaded with the verb, containing no fluff or redundancies.

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

  Completeness4/5

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

  For a simple logout tool with no output schema, the description covers purpose and the key side effect. It lacks details on return values or post-conditions, but these are not necessary for this basic operation.

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

  Parameters4/5

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

  Tool has zero parameters, so schema coverage is 100% and no parameter explanation is needed. Baseline for 0 params is 4.

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

  Purpose5/5

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

  Description uses specific verb 'log out' with resource 'Lufa Farms session', clearly distinguishing from sibling tools like lufa_auth_status and lufa_get_products.

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

  Usage Guidelines3/5

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

  No explicit when/when-not guidance or alternatives named. However, the imperative 'Log out' implies its usage for ending a session, giving minimal but not explicit guidance.

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

• lufa_add_favoriteA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behaviors. It mentions 'Requires an active session' and that favorites 'appear prominently in the marketplace next week,' but it does not describe return values, error handling, or idempotency.

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

  Conciseness5/5

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

  The description is concise, with a clear purpose statement, a short context note, and a well-structured Args block. No unnecessary repetition.

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

  Completeness4/5

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

  The tool is simple with two parameters and no output schema. The description covers purpose, parameters, auth, and a side effect. It lacks return type and edge cases, but overall is complete for a basic toggle operation.

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

  Parameters5/5

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

  Schema descriptions are absent (0% coverage), but the description's Args section fully explains both product_id and favorite, including default behavior. This compensates for the schema gap.

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

  Purpose5/5

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

  The description uses a specific verb ('Add or remove') with a clear resource ('product from the user's favorites list'), distinguishing it from sibling tools like lufa_get_products or lufa_add_to_basket.

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

  Usage Guidelines4/5

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

  The description implies its use for managing favorites and provides context about when favorites matter (next week's marketplace), but does not explicitly state alternatives or exclusions. Since it is the only favorites-related tool, the context is sufficient.

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

• lufa_remove_from_basketA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It discloses that an active session is required, and explains the semantics of the quantity parameter, including the behavior of passing a value greater than or equal to the current basket quantity to remove the entire line. It does not cover error handling or side effects beyond the core behavior, but it provides key behavioral insights for a mutation tool.

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

  Conciseness5/5

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

  The description is concise and well-structured, with a single clear sentence followed by a two-item parameter list. It avoids redundant phrasing and front-loads the essential purpose. The special quantity behavior is explained in one clause without added verbosity.

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

  Completeness4/5

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

  For a simple two-parameter mutation tool, the description covers the core purpose, a prerequisite (active session), and parameter semantics. However, it does not describe the return value (though no output schema exists) or potential error cases such as invalid product_id. Given the tool's simplicity, the description is largely sufficient, but additional details about response or failure modes would make it more complete.

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

  Parameters5/5

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

  The schema provides no descriptions for either parameter, so the description must compensate. It defines product_id as the ID to remove and quantity as the number of units (default 1), and adds the nuanced behavior of removing the entire line when quantity exceeds the current basket quantity. This goes beyond the schema's type-only definitions and gives actionable meaning.

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

  Purpose5/5

  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 ('Remove') and resource ('a quantity of a product from the basket'). This distinguishes it from siblings like lufa_add_to_basket and lufa_view_basket, which add and view respectively. The scope is explicit and unambiguous.

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

  Usage Guidelines3/5

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

  The description implies the tool is for removing items from a basket, but does not explicitly state when to use it over alternatives or when-not. It notes that an active session is required, which is a prerequisite but not a usage guideline comparing to other tools. No alternative tools or exclusion conditions are mentioned, leaving usage to be inferred from the name and context.

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

• lufa_search_productsA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosure. It adds useful context about the tool being a fast, targeted search rather than a full catalog fetch. However, it does not disclose return format, pagination, or whether any side effects or permissions are involved. Since search is inherently read-only, some safety is implied, but the description could be richer.

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

  Conciseness5/5

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

  The description is compact and front-loaded: a one-sentence purpose, a one-sentence usage guideline, and an Args block with a definition and examples. Every sentence adds value; there is no redundancy or filler.

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

  Completeness4/5

  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 no output schema, the description covers the essential dimensions: what it does, when to use it, and the parameter meaning. It omits details about the result structure (e.g., product IDs, names), but given the low complexity and the fact that search results are typically self-explanatory, this is a minor gap.

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

  Parameters5/5

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

  The schema provides only the parameter name 'query' with no description (0% coverage). The description fully compensates by defining query as 'Search term' and providing concrete examples ('heirloom tomatoes', 'sourdough bread', 'goat cheese'), giving the agent clear semantic guidance.

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

  Purpose5/5

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

  The description clearly states the action ('Search'), the resource ('Lufa Farms marketplace'), and the method ('by keyword'). It also distinguishes itself from sibling tools like lufa_get_products by noting it avoids loading the full catalog, making its purpose unambiguous.

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

  Usage Guidelines4/5

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

  It explicitly says when to use this tool: 'to quickly locate a specific item without loading the full catalog.' This implies the alternative is the full-catalog tool (lufa_get_products), providing clear context. However, it does not explicitly name the alternative or state when not to use it, so it falls 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.

• lufa_auth_statusA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description fully explains the behavior: it makes a live request, and if a `note` field is present, session validity is uncertain, with tool calls potentially still working or asking for re-login. This transparently conveys edge cases and what to expect.

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

  Conciseness5/5

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

  The description is concise and well-structured, front-loading the main purpose in the first sentence and then adding necessary nuance in the following sentences. Every sentence contributes value without unnecessary detail.

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

  Completeness4/5

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

  For a simple status-check tool with no parameters and no output schema, the description adequately covers purpose and the caveat around the `note` field. It could be slightly more complete by defining the primary response field (e.g., a boolean indicating active status), but overall it provides enough context for an agent to use the tool correctly.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description correctly provides no parameter information, which is appropriate given the empty input schema.

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

  Purpose5/5

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

  The description clearly states the tool checks whether there is an active Lufa Farms session, using a specific verb and resource. It distinguishes itself from siblings like lufa_logout and lufa_get_products by focusing on session status.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or alternative guidance is given, but the description implies it is the go-to tool for checking session status. It mentions making a live request rather than relying on a saved cookie, which gives some context on its appropriate use, but lacks direct comparison with alternatives.

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

• lufa_get_productsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavioral traits. It adds value by stating 'Requires an active session' and defining the temporal scope (current order week), plus listing the returned fields. It doesn't mention error handling or read-only semantics, but for a simple retrieval, this is adequate.

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

  Conciseness5/5

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

  The description is only three sentences, front-loaded with the primary purpose, followed by a compact list of return fields and a necessary prerequisite. 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.

  Completeness4/5

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

  For a simple no-parameter tool, the description is sufficient: it covers what the tool does, what it returns, and a usage prerequisite. It lacks details like error responses or pagination, but these are not necessary given the tool's simplicity and the absence of an output schema.

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

  Parameters4/5

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

  This tool has zero parameters and 100% schema coverage (empty schema). The baseline for 0-parameter tools is 4, and the description adds no parameter-related info because none is needed. It focuses on the output and preconditions, which is appropriate.

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

  Purpose5/5

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

  The description clearly states 'Retrieve the full product catalog for the current order week', identifying a specific verb (retrieve), resource (product catalog), and scope (full, current order week). This distinguishes it from sibling tools like lufa_search_products and lufa_get_product_details.

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

  Usage Guidelines4/5

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

  The phrase 'full product catalog' and 'current order week' provides clear context that this is the bulk-fetch tool, implicitly indicating to use search_products for filtering. However, it does not explicitly name alternatives or state when not to use it, 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.

• lufa_get_order_detailsA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses what will be returned (delivery date, pickup location, basket breakdown, final totals) and the prerequisite of an active session. For a read-only retrieval tool, this is sufficient, though it does not mention error conditions or side effects.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the primary purpose. Every sentence adds value: the first states the action, the second details the returns and the session requirement. No filler or redundancy.

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

  Completeness5/5

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

  Given the tool has zero parameters and no output schema, the description provides adequate context: it specifies what the tool does, what it returns, and its prerequisite. This is a complete description for a simple order-details lookup.

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

  Parameters4/5

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

  The input schema has zero parameters, and the schema description coverage is 100%. With no parameters to document, the description correctly avoids extraneous parameter information. The baseline for zero-parameter tools is 4.

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

  Purpose5/5

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

  The description uses the specific verb 'Show' with the resource 'current or upcoming order summary', and enumerates the returned components (delivery date, pickup location, basket breakdown, final totals). This clearly distinguishes it from sibling tools like lufa_view_basket and lufa_get_checkout_info.

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

  Usage Guidelines4/5

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

  The description provides clear context by specifying it shows current or upcoming order summaries and requires an active session, but it does not explicitly state when to use this over alternatives or include exclusions. This is clear context without explicit alternative guidance.

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

• lufa_view_basketA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosure. It states the necessity of an active session and describes the return content (items, quantities, unit prices, total). While it doesn't explicitly label the operation as read-only, the verb 'Show' and the context imply no side effects. This adds useful behavioral context beyond the minimal details.

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

  Conciseness5/5

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

  The description is only two sentences, front-loaded with the action and resource, and each sentence adds necessary information (what it shows, what it returns, and the session requirement). No filler or redundant content.

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

  Completeness5/5

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

  For a simple, parameterless view tool with no annotations or output schema, the description is complete. It specifies the tool's output contents and a key precondition (active session). This is sufficient for an agent to decide when to call it and what to expect.

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

  Parameters4/5

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

  The tool has zero parameters, so the description need not explain parameter semantics. Baseline for 0 params is 4, and the description adds value by indicating what the response contains, which helps set expectations for the output.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with a specific verb ('Show') and a clear resource ('current basket contents'), and lists return items (quantities, unit prices, running order total). This distinguishes it from siblings like lufa_add_to_basket and lufa_get_order_details by focusing on the current basket view.

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

  Usage Guidelines4/5

  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 (when you need to see the basket contents) and a prerequisite ('Requires an active session'). It does not explicitly list alternatives or when-not scenarios, but the context is clear enough for an agent to select it correctly among siblings.

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

• lufa_get_product_detailsA
  4.6/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden of disclosing behavior. It states that the tool is a read-only lookup ('Get', 'Returns', 'looked up from the full marketplace catalog'). It does not describe error scenarios (e.g., product not found) or auth requirements, but for a simple get-by-ID tool, this is sufficient context.

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

  Conciseness5/5

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

  The description is concise and front-loaded: the first sentence states the purpose, the second lists return fields, and the third provides source context. The Args section is minimal and relevant. No redundant sentences or unnecessary detail.

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

  Completeness5/5

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

  For a simple tool with one parameter, no output schema, and no annotations, the description covers all essential aspects: what it does, what it returns (specific fields), and where the input ID comes from. It is complete enough for an agent to invoke it correctly without ambiguity.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description includes an Args section that explains the product_id parameter's origin ('Product ID from lufa_get_products or lufa_search_products'), adding significant meaning beyond the schema's bare 'string' type. This tells the agent where to obtain a valid value.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Get detailed information for a specific product.' It specifies the resource (product) and the verb (get), and lists the return fields (name, price, producer, category, weight, organic status). This clearly distinguishes it from sibling tools like lufa_get_products (lists) and lufa_search_products (search), as it focuses on a single product by ID.

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

  Usage Guidelines4/5

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

  The description provides clear context by stating that the product_id comes from lufa_get_products or lufa_search_products, implying this tool is used after obtaining a specific product ID. It does not explicitly mention alternative tools or when not to use it, but the prerequisite and purpose are clear enough for an agent to infer the appropriate usage.

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

• lufa_get_checkout_infoA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: it requires an active session, explains how the two computed fields are derived, and candidly warns that the API has no explicit cutoff field and that the countdown is an approximation. It also notes that Lufa may stop accepting basket changes before the delivery window opens, providing valuable nuance beyond a simple 'retrieve' statement.

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

  Conciseness5/5

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

  The description is three to four sentences, front-loaded with the main purpose, then details the returned fields, then adds the cutoff caveat and session requirement. Every sentence adds value with no redundancy or fluff.

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

  Completeness5/5

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

  Without an output schema, the description thoroughly explains the return values (delivery date, address, window, plus computed fields) and their semantics. It also addresses the accuracy of the countdown and the active-session prerequisite, making the tool's behavior clear in context. Minor error-condition details are absent, but for a no-parameter read-only getter, this is sufficient.

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

  Parameters4/5

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

  The tool takes zero parameters, and the schema is empty. The baseline for 0-parameter tools is 4, and the description appropriately does not need to explain parameter semantics. It focuses on the output and behavior, which is sufficient.

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

  Purpose5/5

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

  The description opens with 'Retrieve delivery metadata for the current order, including a countdown,' which uses a specific verb ('retrieve'), a clear resource ('delivery metadata'), and a distinguishing focus (countdown). It clearly differentiates from siblings like get_order_details by emphasizing delivery timing and computed fields.

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

  Usage Guidelines4/5

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

  The description implies usage context—when you need delivery date, address, time window, and countdown for the current order. It notes the approximate nature of the time remaining, which helps decide whether to rely on it. However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit when-not guidance.

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

• lufa_save_basketA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does excellently. It discloses that the tool is effectively a no-op that trivially returns success, requires an active session, and calls a legacy endpoint with no product specified. This is fully transparent about the behavior and side effects.

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

  Conciseness5/5

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

  The description is concisely written with every sentence serving a purpose: it states the non-essential nature, explains the rationale, describes the actual behavior, and notes the session requirement. It's front-loaded with the most important guidance ('Not required for normal use') and avoids wasted words.

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

  Completeness5/5

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

  For a tool with no schema parameters, no annotations, and no output schema, the description provides a complete picture: what it does, why it exists, when to avoid it, and what to expect (trivial success). It also covers the session requirement. Nothing critical is missing for an agent to decide if and when to invoke it.

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

  Parameters4/5

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

  There are zero parameters, so the description doesn't need to explain individual parameters. The mention that it calls a legacy endpoint 'with no product specified' gives context about why the tool is a no-op, adding value beyond the empty schema. The baseline for zero parameters is 4, and the description matches it.

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

  Purpose5/5

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

  The description clearly states that this tool is a legacy backwards-compatibility no-op that 'returns success trivially.' It explicitly identifies what it does (effectively nothing) and distinguishes it from the actively used basket tools, so the agent understands its exact purpose and scope.

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

  Usage Guidelines5/5

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

  The description explicitly says 'Not required for normal use' and explains that lufa_add_to_basket / lufa_remove_from_basket already persist to the server immediately. It also notes there is no confirm-order step in Lufa's site, providing clear when-not-to-use guidance and naming the alternatives.

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

• lufa_add_to_basketA
  5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals immediate effect (no draft state), the increment semantics of quantity, the separate product ID treatment for variants, and the session requirement. These are non-obvious behaviors that an agent needs to know, and they are stated clearly and confidently.

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

  Conciseness5/5

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

  The description is concise and front-loaded with the primary action. The additional paragraphs add valuable context without fluff, and the Args section cleanly separates parameter explanations. Every sentence earns its place with unique information, and the structure makes it easy to scan.

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

  Completeness5/5

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

  For a simple two-parameter tool, the description covers everything needed: how to add, what to know about variants, the increment behavior, session requirement, and the immediate effect. It even references the related tool for finding product variants. There is no output schema, but the description doesn't need to explain return values given the tool's straightforward purpose.

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

  Parameters5/5

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

  The schema provides no parameter descriptions (0% coverage), so the description compensates fully. It explains that product_id is the ID to add and that quantity is an increment on top of the current basket quantity, not an absolute target. This goes beyond the schema's bare type/default information, giving actionable meaning to both parameters.

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

  Purpose5/5

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

  The description opens with 'Add a product to the basket,' a specific verb+resource statement that clearly identifies the tool's function. It further distinguishes from siblings like lufa_remove_from_basket and lufa_view_basket by focusing exclusively on the add operation and the immediate effect of the change.

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

  Usage Guidelines5/5

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

  Provides clear when-to-use context: add products, with a note that no save_basket is needed since changes take effect immediately. It also gives explicit guidance on handling product variants—check sub_products via lufa_get_product_details—and prerequisites like requiring an active session. This exceeds simple implied usage by offering an alternative workflow.

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