Server Quality Checklist

Tool Scores

• add_to_cartC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While 'Add an item' implies a write/mutation operation, it doesn't disclose important behavioral traits: whether this requires authentication, if it modifies existing cart state, what happens on duplicate items, error conditions, or what the response looks like. For a mutation tool with zero annotation coverage, this 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.

  Conciseness5/5

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

  The description is a single, clear sentence with zero wasted words. It's appropriately sized for this tool and front-loads the essential information. Every word earns its place in conveying the core purpose efficiently.

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

  Completeness2/5

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

  For a mutation tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address authentication requirements, error handling, response format, or how this integrates with the cart management workflow involving sibling tools. The agent lacks sufficient context to use this tool effectively in real scenarios.

  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 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. It doesn't explain relationships between parameters (e.g., that storeId, menuId, and itemId should be consistent) or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

  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 action ('Add an item') and target ('to your DoorDash cart'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'remove_from_cart' or explain how it relates to 'list_carts' in terms of cart management workflow.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing to be logged in via 'login_check'), how it interacts with 'list_carts' for viewing cart contents, or when to use 'remove_from_cart' instead. There's no context about when this operation is appropriate.

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

• get_store_menuC
  2.9/5.0
  Behavior2/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 states the tool retrieves a 'full menu with items and prices', implying a read-only operation, but doesn't cover critical aspects like error handling (e.g., invalid store IDs), rate limits, authentication needs, or response format. This is a significant gap for a tool with no annotation support.

  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 a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  Given the tool's complexity (a read operation with two parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the return value includes (e.g., structure of items/prices), error conditions, or dependencies on other tools (e.g., 'storeId' from 'search_restaurants'). This leaves gaps for effective agent use.

  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?

  The schema description coverage is 100%, so the schema already documents both parameters ('storeId' and optional 'menuId') adequately. The description adds no additional parameter semantics beyond implying the tool fetches menu data, which is redundant with the schema. This meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('store's full menu with items and prices'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_restaurants' or 'order_history', which might also involve menu-related operations, so it falls short of a perfect score.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a store ID from search results), exclusions, or comparisons to siblings like 'search_restaurants' (which might return menu snippets). This lack of context leaves the agent to infer usage.

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

• remove_from_cartC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('remove') which implies a destructive mutation, but provides no information about permissions required, whether changes are reversible, error conditions, or what happens to the cart after removal. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

  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 a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple tool and front-loads the essential information. Every word earns its place in this concise formulation.

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

  Completeness2/5

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

  For a destructive mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (success confirmation? updated cart?), error conditions, or behavioral implications. Given the complexity of cart manipulation and the lack of structured safety information, the description should provide more operational context.

  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 100%, with both parameters clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

  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 action ('remove') and target resource ('item from your DoorDash cart'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'add_to_cart' or 'list_carts', but the verb 'remove' provides inherent differentiation. This is clear but lacks explicit sibling comparison.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a cart ID from 'list_carts'), when removal is appropriate versus modifying quantities, or what happens if the item doesn't exist. Without any usage context, the agent must infer everything from the tool name alone.

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

• search_restaurantsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Search' implies a read-only operation, the description doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the results take. For a search tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.

  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 at just 7 words: 'Search for restaurants and food on DoorDash'. It's front-loaded with the core purpose, contains zero wasted words, and efficiently communicates the essential information in a single, clear sentence.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete for a search tool. It doesn't explain what the search returns (restaurant listings? menu items? availability?), whether authentication is required, how results are structured, or any limitations. For a tool that presumably returns complex search results, this minimal description leaves too many contextual questions unanswered.

  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?

  The input schema has 100% description coverage, with the single 'query' parameter clearly documented as 'Search query (e.g. 'pizza', 'sushi', 'McDonald\'s')'. The description doesn't add any additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate when the schema does the heavy lifting.

  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's purpose: 'Search for restaurants and food on DoorDash'. It specifies the verb ('Search') and resource ('restaurants and food'), and identifies the platform ('DoorDash'). However, it doesn't explicitly differentiate this search tool from potential sibling tools like 'get_store_menu' or 'list_carts', which might also involve restaurant/food information.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this search tool should be used instead of 'get_store_menu' (which might retrieve specific menu details) or 'list_carts' (which might show cart contents). There's no context about prerequisites, timing, or exclusions for using this search functionality.

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

• login_checkB
  3.1/5.0
  Behavior2/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 states what the tool does but doesn't describe the return format (e.g., boolean, status object), error conditions, or any side effects. For a tool with zero annotation coverage, this is insufficient, though it at least correctly indicates a read-only check operation.

  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 a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action. Every part of the sentence earns its place, making it highly concise and well-structured.

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

  Completeness2/5

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

  Given the tool's simplicity (zero parameters, no output schema, no annotations), the description is minimal but adequate for basic understanding. However, it lacks details on the return value or behavioral context, which are important for an agent to use it effectively. With no output schema, the description should ideally hint at what 'active' means or what format the check returns.

  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, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied for zero-parameter tools when the schema is fully covered.

  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's purpose with a specific verb ('check') and resource ('DoorDash session'), making it immediately understandable. It doesn't explicitly differentiate from sibling tools, but since none of the siblings appear to perform session status checks, this is adequate for a 4.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a session must exist first), timing (e.g., before performing other operations), or what to do based on the result. This leaves the agent with minimal context for decision-making.

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

• order_historyB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but provides no information about authentication requirements, rate limits, error conditions, response format, or whether this is a read-only operation. 'Get' implies read-only, but this isn't explicitly confirmed.

  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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.

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

  Completeness3/5

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

  For a simple read operation with one well-documented parameter and no output schema, the description is minimally adequate. However, it lacks important context about authentication, response format, and error handling that would be helpful for an agent to use this tool effectively.

  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 100%, so the schema already fully documents the single 'limit' parameter. The description doesn't add any parameter semantics beyond what's in the schema, but with complete schema coverage, the baseline is 3.

  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 action ('Get') and resource ('recent DoorDash order history'), making the tool's purpose immediately understandable. It doesn't differentiate from siblings, but none of the listed sibling tools appear to directly overlap with order history retrieval, so a 4 is appropriate.

  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?

  The description provides no guidance on when to use this tool versus alternatives. While sibling tools like 'search_restaurants' or 'list_carts' serve different purposes, there's no explicit comparison or context about when order history retrieval is appropriate versus other data access tools.

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

• list_cartsB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states 'List all active DoorDash carts' which implies a read-only operation, but doesn't specify what 'active' means, whether it requires authentication, how results are formatted, or if there are rate limits. For a tool with zero annotation coverage, this leaves significant gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality immediately.

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

  Completeness3/5

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

  Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It explains what the tool does but lacks behavioral context (like auth requirements or result format) that would be helpful for an agent. For a basic list tool, it meets minimum viability but has clear gaps.

  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 0 parameters with 100% schema description coverage, so the schema already fully documents the absence of inputs. The description adds no parameter information (which isn't needed), maintaining the baseline of 4 for zero-parameter tools as per the guidelines.

  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 action ('List') and target resource ('all active DoorDash carts'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'order_history' or 'search_restaurants', but the verb+resource combination is specific enough for basic understanding.

  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?

  The description provides no guidance on when to use this tool versus alternatives like 'order_history' (which might show past orders) or 'add_to_cart' (which modifies carts). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from tool names alone.

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