Server Quality Checklist

Tool Scores

• get_adC
  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 must describe behavioral traits like side effects (none expected since it's a get operation), authentication requirements, or rate limits. It only states the action without any behavioral context, leaving the agent unsure about safety or data persistence.

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

  Conciseness4/5

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

  The description is a concise single sentence that front-loads the purpose. Every word contributes meaning, with no superfluous content.

  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 simple tool (1 param, no output schema, no annotations), the description is acceptable but lacking completeness. An ideal description would mention the expected response structure, what 'full details' includes, or any error cases (e.g., what happens with an invalid ID).

  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 already covers the single parameter 'id' with 100% description coverage ('The Cart ad ID.'). The description adds 'by its Cart ad ID' which mildly clarifies the source, but since schema coverage is already high, the baseline is 3—adequate but not adding transformative value.

  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 details for a single ad by ID, using a specific verb ('Get') and resource ('advertisement by its Cart ad ID'). It distinguishes itself from sibling tools like search_ads and get_store_ads by focusing on a single ad and requiring a specific ID.

  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 such as search_ads or get_store_ads. It doesn't clarify prerequisites (e.g., needing a Cart ad ID from a prior search) or situations where other tools would be more appropriate.

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

• get_store_adsB
  3.1/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. It describes a read operation and key return fields, but does not disclose pagination behavior, rate limits, authentication requirements, or whether returned data is complete or filtered. 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?

  Two sentences with no wasted words. The purpose is front-loaded and the return structure is quickly summarized. Excellent conciseness.

  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?

  The description lists key return fields, which is helpful given the lack of an output schema. However, it does not mention potential pagination, the number of ads returned, or how this tool relates to sibling tools like 'search_ads' and 'get_ad'. This leaves the agent with incomplete context for selecting and invoking the tool correctly.

  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 coverage is 100% for the single parameter 'domain', which is already described as 'The store domain (e.g. 'gymshark.com').' The description adds no additional semantic context beyond what the schema provides, so a baseline of 3 is appropriate.

  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 it gets advertisements for a specific store and lists the returned fields (platform, image URL, landing URL, date range). However, it does not distinguish itself from sibling tools 'search_ads' and 'get_ad', which could overlap.

  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 only says 'for a specific store' but provides no guidance on when to use this tool versus alternatives like 'search_ads' (which may search across stores) or 'get_ad' (which may retrieve a single ad). No exclusions or context for appropriate use are given.

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

• search_suppliersB
  3.2/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 full burden. It only states the tool searches and filters, but does not disclose pagination behavior, result limits, data freshness, or any other behavioral traits. This is insufficient for a tool with 6 parameters.

  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 sentences, front-loaded with the primary action, and contains no unnecessary words. Every sentence serves a purpose.

  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 has 6 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the search behavior, pagination, default sort, or what the response contains. The agent would need to infer too much from the parameter names alone.

  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 parameters are already well-documented. The description redundantly mentions keyword, location, and type filters but adds no new semantic information beyond what is in the schema. Baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool searches for product suppliers and vendors, and mentions filtering by keyword, location, or type. It distinguishes the resource (suppliers) from sibling search tools but does not explicitly differentiate why this tool should be used over search_stores or search_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?

  The description says 'Useful for finding sourcing and manufacturing partners,' which implies a use case, but it provides no guidance on when not to use this tool or how it compares to alternatives like search_stores or search_products.

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

• search_adsA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses return contents (creatives, platform, images, URLs, date ranges) but does not state that the tool is read-only, mention pagination behavior, rate limits, or authentication requirements. Some gaps remain, but the core behavior is moderately transparent.

  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 sentences: first states purpose and filters, second states return content. Efficient, front-loaded, and no wasted words.

  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 6 optional parameters, no output schema, and 14 sibling tools, the description is adequate but incomplete. It lacks details on default sort, pagination behavior, and differentiation from related tools. It does not mention prerequisites or if the tool is read-only.

  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 covers all 6 parameters with descriptions (100% coverage), so the baseline is 3. The description mentions 'keyword' and 'store_domain' but adds no new meaning beyond the schema. It provides context on return fields but not on how parameters affect results.

  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 verb 'Search', the resource 'e-commerce advertisements', and the scope 'across platforms'. It lists filtering options and return fields, making the tool's purpose specific and distinct from siblings like 'get_ad' (singular) or 'search_stores'.

  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 does not provide any guidance on when to use this tool versus alternatives such as 'get_store_ads' or 'get_ad'. It only implies usage for filtering by keyword or store domain, but no explicit when-to-use or when-not-to-use information.

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

• search_productsA
  3.5/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 full burden. It states it performs a search and returns fields, but does not disclose behavioral traits such as pagination behavior, sorting defaults, case sensitivity, rate limits, or authentication needs. The read-only nature is not explicitly asserted.

  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?

  Two sentences with no fluff. The purpose is front-loaded: 'Search the Cart product database across all tracked stores.' Each sentence contributes value and the structure is efficient.

  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?

  With 7 parameters, no output schema, and no annotations, the description is brief. It covers basic functionality and return fields but omits details like pagination defaults, sorting behavior, error handling, and currency handling. Adequate but incomplete for a moderately complex tool.

  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 baseline is 3. The description (e.g., 'Filter by keyword, price range, and currency') maps to existing schema descriptions but adds no new meaning or context beyond what the schema already provides for each parameter.

  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 verb 'Search' and the resource 'Cart product database across all tracked stores.' It specifies filtering capabilities and return fields, making it distinct from siblings like 'search_stores' (which searches stores) and 'get_product' (single product).

  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 use for broad product search but does not explicitly state when to use this tool versus alternatives like 'search_stores' or 'get_product.' No exclusion criteria or when-not-to-use guidance is provided.

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

• compare_storesA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It states that the tool returns 'full store profiles' for comparison, indicating a read operation, but does not disclose details like data freshness, authentication needs, or whether results are real-time or cached. The behavioral description is adequate but not rich.

  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 sentences, front-loaded with the core purpose, and every word adds value. No redundancy or fluff. It is efficient and easy to parse.

  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?

  Given the tool's moderate complexity, the description covers the input range, the action, and the return value ('full store profiles' with examples of data like traffic, products, platforms). No output schema exists, so the description partially compensates by explaining the output. It could be more exhaustive about the exact fields, but it is sufficient for an agent to understand the tool's role.

  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 coverage is 100% with a single parameter (domains) fully described. The description adds context by specifying 'e-commerce stores' and the output type ('full store profiles'), but these are minor enhancements. The baseline is 3, as the schema already handles the parameter definition well.

  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 'compare' and the resource 'e-commerce stores', with a specific range of 2 to 10. It distinguishes from siblings like search_stores and get_store by focusing on side-by-side comparison of multiple stores. However, it does not explicitly differentiate from the individual get_store_* tools that return specific aspects, which could be used for comparison as well.

  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 comparing multiple stores, but it provides no guidance on when not to use it (e.g., for a single store's data) or alternatives like get_store_traffic for specific metrics. The context is clear for the intended use case, but lacks explicit exclusions or sibling references.

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

• get_storeA
  3.6/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. It states the operation is a read (get) and lists returned fields, but does not reveal any safety profile, error behaviors, authentication requirements, rate limits, or other behavioral traits. Important context for an agent is missing.

  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 sentences: the first states the core action, the second enumerates key return fields. It is front-loaded, efficient, and contains no superfluous information. Every word earns its place.

  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?

  Given no output schema, the description adequately explains return values by listing several specific data points (traffic, product count, platform, etc.). It covers the core purpose and parameter usage. However, it omits error handling context and prerequisites (e.g., whether the store must exist in the database). For a simple single-parameter tool, it is largely complete but has minor gaps.

  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 coverage is 100% with a well-described 'domain' parameter including examples and format instructions. The description restates that lookup is 'by its domain' but adds no new semantic information beyond what the schema provides. Baseline is 3 by the scoring rule.

  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 verb 'Get' and the resource 'full profile for a single e-commerce store by its domain'. It lists specific return fields (traffic stats, product count, platform, social links, business model flags), which distinguishes it from sibling tools like get_store_traffic or get_store_products that only provide subsets of this data. This makes the tool's unique purpose immediately clear.

  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 usage when the full store profile is needed by domain, but it does not explicitly state when to use this tool over siblings like search_stores (for listing stores) or get_store_traffic (for just traffic data). No alternatives or exclusions are mentioned, so guidance is only implicit.

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

• get_trendingA
  3.7/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 full responsibility. It merely restates the tool's purpose ('Get trending products and rapidly growing stores') without disclosing behavioral traits such as read-only nature, pagination behavior, data freshness, or output structure. The description adds minimal value beyond the tool's name.

  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: two sentences that immediately convey the tool's purpose and context. Every word earns its place, with no wasted text.

  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?

  Despite the sparse description, the tool has only three optional parameters and no output schema. The description covers the high-level purpose but lacks details on what 'trending' means algorithmically, how results are ordered, or the structure of the response. It is minimally adequate but leaves gaps for an agent.

  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 for all three parameters (page, category, per_page), so the schema alone adequately documents parameter semantics. The tool description does not mention parameters or add any extra meaning, placing it at the baseline of 3.

  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: 'Get trending products and rapidly growing stores.' This is a specific verb+resource combination that distinguishes it from sibling tools like search_products or search_stores, which focus on searching rather than surfacing trending items.

  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 includes a usage context: 'Useful for identifying hot products, emerging niches, and fast-rising stores.' This provides clear scenarios for when the tool is appropriate. However, it does not explicitly mention when not to use it or compare with sibling tools like search_products, which might be preferred for targeted queries.

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

• search_storesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description bears full responsibility for behavioral disclosure. It mentions pagination and return fields (traffic, products, platform) but lacks details on pagination behavior (e.g., how to navigate pages, default page, max page), rate limits, or whether the operation is read-only. The description is adequate but not comprehensive.

  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 sentences that are front-loaded and concise. The first sentence states the main action and database, the second sentence lists filters and output. Every sentence contributes value without unnecessary words.

  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 7 optional parameters, no required param, no output schema, and no annotations, the description covers the basic purpose and return type but lacks details on pagination mechanics (e.g., default per_page, page limits) and output structure. It is minimally complete but could be improved for a search tool with multiple filters.

  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 baseline is 3. The description adds examples for keyword and platform (e.g., 'pet supplies', 'shopify'), providing minor value beyond the schema. However, it does not cover all parameters or provide deeper semantic meaning, so it remains at a 3.

  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 searches the Cart database of e-commerce stores with specific filters, and mentions returns a paginated list of store summaries with traffic metrics, product counts, and platform info. This verb+resource combination is specific and distinguishes it from sibling tools like get_store (single store) or search_products (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?

  The description implies usage by listing filters and return type, but does not explicitly state when to use this tool versus alternatives (e.g., get_store for a single store, search_products for products). No when-to-use or when-not-to-use guidance is provided. The context of sibling tools exists but is not referenced in the description.

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

• get_store_productsA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It indicates the tool is read-only ('List') and returns paginated results, which is good. However, it does not disclose any rate limits, authentication requirements, or whether the pagination is cursor-based or page-based beyond the 'page' parameter. The description adds value but misses some behavioral details.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main action and resource, and every sentence adds value. The first sentence states the core purpose, and the second summarizes the return fields. No wasted words.

  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 list tool with 4 parameters, no output schema, and no annotations, the description is fairly complete. It covers the input (domain), output structure (titles, prices, images, vendors), and pagination hint. However, it doesn't mention that the response might include total count or next page links, which would be helpful for pagination-aware agents.

  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 parameters well. The description adds minimal extra meaning beyond the schema—it mentions 'paginated list' which aligns with the page/per_page params, but doesn't explain the sort format or what 'added_at' means. Given high coverage, baseline 3 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 the verb 'List' and the resource 'products sold by a specific e-commerce store', and distinguishes it from sibling tools like 'search_products' (which likely searches across stores) and 'get_product' (which gets a single product). It also mentions the return fields, making the purpose very specific.

  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 usage when you need to list products for a given store domain, but it does not explicitly say when not to use it or suggest alternatives. For example, it doesn't mention that 'search_products' might be better for cross-store queries, or that 'get_product' is for a single product. The context is clear but lacks exclusionary guidance.

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

• get_productA
  3.9/5.0
  Behavior3/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. It lists the return fields (title, price, image, vendor, store domain, timestamps), which is helpful, but it does not mention any side effects, authorization needs, rate limits, or explicitly confirm it is a read-only operation. The implied read-only nature of a 'Get' is reasonable but not explicitly stated.

  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 that states the purpose and lists useful return fields. It is front-loaded with the action and resource, and every part contributes meaningfully with no wasted words.

  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 tool with one parameter and no output schema, the description provides the action and a list of returned fields. However, it claims to return 'full details' but only lists six fields, leaving questions about other potential fields (e.g., description, variants). Also, 'timestamps' is vague without specifying which timestamps or their format. The description could be more precise to fully inform the agent.

  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 covers the sole parameter 'id' with a description ('The Cart product ID.'), and the description restates it as 'by its Cart product ID.' Since schema description coverage is 100%, the description adds no new meaning beyond what the schema already provides. The baseline of 3 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 uses a specific verb ('Get') and resource ('product') with a clear identifier ('by its Cart product ID'). It distinguishes effectively from sibling tools like 'search_products' (which finds products by criteria) and 'get_store_products' (which lists all products for a store).

  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 clearly states the context: use this tool to retrieve full details for a single product when you have its Cart product ID. While it does not explicitly mention when not to use it or name alternatives, the context is clear enough for an agent to infer that this is for specific-ID lookups, and sibling tools like 'search_products' exist for other scenarios.

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

• get_niche_overviewA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It clearly indicates read-only behavior ('Get a market overview') and lists returned data, which suffices for a non-destructive tool. It does not mention authentication or rate limits, but this is acceptable given the simple nature of the 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 two sentences: first defines purpose and outputs, second adds usage context. No redundant wording. It is front-loaded with the core action and immediately useful, earning full marks for conciseness.

  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?

  Despite lacking an output schema, the description enumerates all returned data elements, making it complete for its single-parameter, non-nested structure. It could briefly mention that results are aggregated, but it is sufficient given the tool's simplicity and sibling 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% (keyword parameter described with examples). The tool description adds no further parameter details beyond 'niche keyword', so the schema already fully documents it. Baseline 3 is appropriate as description provides no additional 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 retrieves a market overview for a niche keyword, specifying exact return data (total stores/products, average price, top stores, trending products). This distinctly differentiates it from sibling tools like search_stores or get_store_products, which focus on individual entities.

  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 explicitly frames usage for 'market research and competitive analysis', providing clear context. However, it does not include explicit exclusions or alternative tool references for when not to use it, leaving some ambiguity compared to a top-tier score.

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

• get_store_techA
  4.2/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 full burden. It explicitly states the action (get) and the return type (a list of technologies with categories). This gives enough behavioral context for a read operation. There is no mention of any other side effects, but for a simple query tool, this is sufficient. A 4 is appropriate because it is transparent about what it does and returns.

  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 consists of two sentences that are perfectly front-loaded: the first sentence states the core purpose, and the second elaborates on the output. Every word earns its place with no fluff. This is an excellent example of concise documentation.

  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?

  Given that the tool has a simple interface (one required parameter, no nested objects, no output schema), the description is complete enough for an agent to use it correctly. It explains both input and output. A higher score would require returning values documented, but since there is no output schema, the description adequately covers what is returned.

  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% (the 'domain' parameter is described in the schema). The description adds context about what the parameter is used for (the store domain) but not beyond the schema's own 'description' field. Since the schema already handles the parameter documentation, the description adds minimal extra value, scoring a baseline 3.

  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 ('Get') and clearly identifies the resource ('the technology stack used by a store'), and further specifies the output ('a list of technologies with their categories'). This effectively distinguishes it from sibling tools like get_store, get_store_products, and get_store_traffic, which all target different resources.

  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 by focusing on store technology stack, but it does not explicitly state when to use this tool versus alternatives (e.g., it doesn't say 'Use this to analyze store tech, not to get store details'). It provides no exclusions or when-not-to-use guidance, so it gets a 4 for being clear but not providing alternative guidance.

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

• get_store_trafficA
  4.2/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the full burden of behavioral disclosure. It explicitly lists the return data categories (geographic breakdown, traffic sources, etc.), which gives the agent a clear picture of what to expect. However, it does not disclose whether the data is real-time, historically aggregated, or whether store-level permissions are required. Given the absence of annotations, this is quite transparent but not exhaustive.

  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, well-structured sentence that front-loads the core purpose ('Get detailed traffic analytics for a store') and then enumerates the specific metrics. Every phrase earns its place; there is no redundancy or wordiness. Ideal for an agent to quickly parse.

  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?

  Given the tool has a single required parameter, no output schema, and no nested objects, the description is appropriately complete. It explains the input (domain) and the full set of outputs (7+ data categories). However, it lacks any mention of return format or potential errors (e.g., invalid domain). For a simple read tool with no annotations, this is largely sufficient but not fully exhaustive.

  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 100% description coverage for its single parameter domain, with schema description 'The store domain (e.g. 'gymshark.com').' The tool description reinforces this by stating 'for a store' and listing metrics, which adds context about the scope of analytics but does not add new meaning beyond the schema's clear `domain` parameter. With perfect schema coverage and only one parameter, the description provides slight additional context (the type of analytics), warranting a score above baseline 3.

  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 starts with a clear verb phrase 'Get detailed traffic analytics for a store' and precisely lists the specific metrics returned (monthly visitors, trend percentage, bounce rate, etc.). It effectively distinguishes itself from sibling tools like get_store_products or get_store_ads, which cover different domains of store data.

  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 usage for retrieving store traffic data, but provides no explicit when-to-use or when-not-to-use guidance. While the context of 'a store' is clear, there is no comparison to siblings like get_store (which may provide broader analytics) or search_stores (which may filter stores). The tool's exclusive reliance on a domain parameter is implied, but not clarified as a constraint.

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

• get_accountA
  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 full burden of disclosing behavioral traits. The description clearly indicates it is a read operation ('get information') and implicitly requires authentication through 'authenticated account.' It does not hide any side effects or destructive actions. For a simple tool with no parameters and no complex behavior, this is sufficiently transparent.

  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, focused sentence that immediately conveys the tool's purpose and key information. Every word adds value, and the most important action ('Get information about the authenticated Cart API account') is front-loaded. No extraneous 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?

  Given the tool has no parameters, no output schema, and covers a simple account info retrieval, the description is complete. It lists the specific fields returned (plan, email, daily request count, request limit) and provides actionable context (check remaining API quota). There are no gaps in coverage.

  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, and the schema coverage is 100%. According to guidelines, when there are no parameters, the baseline is 4. The description does not need to add parameter information because there are none to describe.

  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 gets information about the authenticated Cart API account, listing specific fields (plan, email, daily request count, request limit). This verb and resource combination is distinct from all sibling tools, which focus on stores, products, ads, and suppliers, with no other tool retrieving account-level data.

  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 explicitly states 'Use this to check remaining API quota,' providing clear usage context. While it does not specify when not to use it, there are no sibling tools that serve a similar purpose, so exclusion guidance is not necessary. The guidance is direct and helpful.

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