Server Quality Checklist

Tool Scores

• get_price_statsB
  3.2/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. It discloses that statistics are computed from the 60 cheapest matching listings sorted ascending, which helps an agent understand potential skew, and notes 'One polite request' about request behavior. It doesn't address rate limits or errors, but for a read-only stats tool this is reasonably transparent.

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

  Conciseness4/5

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

  The description is a single, focused sentence followed by a short note. It front-loads the purpose and then lists computed values and methodology. The 'One polite request' fragment is slightly ambiguous but not bloated.

  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 10-parameter tool with no output schema and no annotations, the description explains the core computation and output fields, which is essential. However, it omits how unspecified parameters behave, what the response structure looks like beyond the stats list, and the meaning of the 'polite request' note. Some gaps remain.

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

  Parameters2/5

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

  The description adds no per-parameter meaning. Schema covers 70% of parameters, leaving year, condition, and countries without descriptions, and the tool description does not compensate or clarify how filters affect the statistics. It only refers to 'matching listings' generically.

  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 computes price statistics (min, percentiles, max, sample size) for watches across Chrono24. Although it uses a noun phrase rather than a verb, the function is unambiguous. It doesn't explicitly differentiate from siblings like search_listings, but the aggregated-statistics deliverable is distinct.

  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 given on when to call this tool compared to search_listings, get_watch, or get_dealer_listings. The description only says what the tool returns, not when it is the right choice. There is no mention of alternatives or exclusions.

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

• get_dealer_listingsB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavioral traits. It mentions 'current inventory' (data freshness) and 'Same card shape as search_listings' (output format), which is useful. It does not state whether the operation is read-only or requires authentication, but for a listing tool these may be less critical. The provided info is moderately helpful 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 with zero filler. The primary purpose and key parameter are front-loaded in the first sentence, and the output shape is mentioned in the second. Every word contributes value; it is exemplary in brevity and structure.

  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 three-parameter tool with no output schema, the description gives the essential purpose and hints at return format via 'Same card shape as search_listings'. It does not explain pagination behavior, sort options, or potential errors. Given the low schema coverage, more context would be beneficial, but the description is adequate for basic invocation.

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

  Parameters2/5

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

  Schema description coverage is only 33% (only customerId has a description). The tool description repeats the customerId context already in the schema ('from get_watch's sellerIds') and provides no additional meaning for the 'page' or 'sort' parameters. Since coverage is low, the description should compensate, but it does not, leaving those parameters under-explained.

  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 lists a dealer's current inventory by customerId, which is a specific verb+resource combination. It references get_watch as the source of the ID, adding precision. It does not explicitly differentiate itself from siblings like search_listings, though the name and the customerId reference imply a narrower scope.

  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 should be used when you have a dealer's customerId from get_watch, providing a clear usage context. However, it does not explicitly state when to prefer this over search_listings or list_brands, nor does it mention any exclusions or prerequisites beyond the customerId source.

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

• search_listingsA
  3.8/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 behavioral burden. It clearly discloses pagination ('up to 60 cards per page'), the exact field set returned, and the shortlist-level scope ('without fetching details'). This gives the agent a concrete model of what the call will produce, even though it does not discuss sort defaults or empty-result behavior.

  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 tight sentences with no filler. The verb and resource are front-loaded, and the second sentence earns its place by describing return shape and intended use. Nothing extraneous is present.

  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?

  There is no output schema, so describing the returned card fields is essential and the description does so. It also communicates pagination and the shortlisting purpose. Given the rich parameter schema that already documents every parameter, the description covers the main gaps without needing to repeat schema details.

  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% coverage, so the baseline is 3 and the description does not need to add much. The description adds no real parameter-level meaning beyond what the schema already documents, such as the meaning of query, facets, or limit. Thus it neither helps nor hurts beyond the schema.

  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 states a specific action and resource: 'Search Chrono24 watch listings.' It also enumerates the returned fields, making clear this is a listing-level search tool. It does not explicitly contrast with siblings like get_dealer_listings or get_watches, so it stops short of a 5.

  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 phrase 'enough to shortlist without fetching details' implies a search/shortlisting use case, giving some context. However, it does not state when to prefer this tool over get_dealer_listings, get_watches, find_models, or list_filters, nor does it give any when-not-to-use guidance.

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

• find_modelsA
  4/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states the tool lists a catalog, which implies a read-only operation, but does not disclose potential limitations such as pagination, rate limits, or required permissions. It also doesn't describe the exact output structure beyond naming fields, but that is mentioned in the purpose. This is adequate for a simple read operation but lacks deeper behavioral 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 two sentences with zero redundancy. It front-loads the core purpose ('List a brand's model catalog') and then provides a practical tip on pairing the result with search_listings. Every sentence earns its place, and the structure is efficient and clear.

  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 tool with only one parameter and no output schema, the description provides essential information: what the tool returns (model name, slug, id) and how to leverage those values in another tool. It lacks explicit error handling or edge-case guidance, but given the low complexity and the presence of a rich schema for the parameter, it is nearly complete. The only missing piece is a more explicit output format specification.

  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 already provides a comprehensive description of the 'brand' parameter, covering name, ID, and slug formats (100% coverage). The tool description does not add new meaning about the parameter itself; it only instructs how to use the output values (model id and brand id) with search_listings. Since the schema already documents the parameter thoroughly, the baseline of 3 applies.

  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: 'List a brand's model catalog (model name, slug and numeric model id)'. It names a specific verb ('list') and resource ('model catalog'), specifies the returned fields, and distinguishes itself by describing the catalog scope. This is unambiguous and sufficient for an agent to know what it does.

  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 practical usage context by instructing how to connect the output to other tools: 'Pair the model id with search_listings' models param and the brand id with manufacturerIds'. It implies when to use it (when you need a brand's model IDs) without explicitly listing exclusions or alternatives. It gives clear context, though it doesn't mention when not to use it or alternative tools.

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

• get_watchA
  4/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. It lists the response components (reference, specs, box/papers, dealer info, photos, URL), which is useful, but it does not mention error behavior (e.g., invalid or missing ID), rate limits, or any operational constraints. For a read-only fetch this is adequate 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?

  A single sentence that front-loads the primary action and resource, followed by a concise list of returned details. There is no filler, redundancy, or unnecessary elaboration—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?

  For a single-item fetch with no output schema, the description clearly states what will be returned (types of details, photos, URL). It does not mention potential failure cases (e.g., 'null if not found'), but the operation is simple and the description covers the essential information an agent needs to decide to call it and interpret the result.

  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 the parameter fully described (Chrono24 listing id, digits, extraction from URL). The description merely repeats 'by id' without adding novel semantics. The baseline of 3 applies since the schema carries the weight.

  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') with a concrete resource ('full details for one Chrono24 listing by id') and enumerates the included content (reference, specs, box/papers, dealer info, photos, canonical URL). It clearly differentiates from siblings like search_listings and get_watches (plural) by focusing on a single listing 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 phrase 'by id' establishes that this tool is for retrieving a specific listing when the ID is known, implying it is not for searching or listing. It does not explicitly name alternatives or exclusion conditions, but the usage context is clear and unambiguous.

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

• get_watchesA
  4/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 of behavioral disclosure. It proactively states 'Runs politely and sequentially; uncached ids take ~4s each,' which informs an agent about rate-limiting politeness, sequential execution, and timing expectations. This is useful context that goes beyond the schema, though it does not cover error handling or failure modes.

  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-formed sentence that front-loads the core action ('Get full details...') followed by key behavioral constraints. Every clause adds value: the shortlist limit, the politeness, and the timing. 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 tool with one parameter, high schema coverage, and no output schema, the description provides sufficient information for an agent to call it accurately. It covers the scope (shortlist, limit), the behavior (polite, sequential, timing), and the purpose. It might benefit from mentioning return format, but that is not critical given the tool's simplicity.

  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 the 'ids' parameter with details on limits and cost. The description adds the behavioral nuance of politeness and timing, which indirectly touches on request cost, but does not add new meaning to the parameter itself. Thus, a baseline score 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 clearly states the verb 'Get' and the resource 'full details for a shortlist of up to 10 Chrono24 listing ids.' It explicitly limits to a shortlist of up to 10, distinguishing it from get_watch (singular) and search_listings by focusing on fetching details for multiple known ids.

  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 a batch of up to 10 listing ids, but it does not explicitly state when to prefer this over get_watch (for single ids) or search_listings (for finding listings). The mention of 'shortlist' hints at a use case but does not provide explicit when/when-not guidance or mention alternative tools.

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

• list_filtersA
  4.1/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 behavioral disclosure burden. It makes the read-only nature clear via 'List' and describes the output content ('allowed values'). However, it does not disclose output format, pagination, error behavior, or any auth/rate-limit requirements. For a simple listing tool this 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 short sentences with no filler. The primary purpose is front-loaded, examples are compact, and the downstream usage guidance earns its place.

  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 optional-parameter listing tool, the description plus schema fully cover what an agent needs: what is listed, what values look like, how to use them with search_listings, and how the optional name parameter behaves. No output schema is present, but the description sufficiently describes what will be 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?

  The schema already provides 100% coverage for the optional 'name' parameter, including an example value and behavior when omitted. The description does not add parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and resource ('Chrono24 search facet filters'), and specifies the content returned ('allowed values'). The examples clearly distinguish this from sibling tools like list_brands or search_listings.

  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 connects this tool to search_listings: 'Use values with search_listings' facets param.' This gives clear downstream context for when to use it. It does not explicitly mention when not to use it or name alternatives, but the intended usage is clear.

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

• get_dealer_ratingsA
  4.2/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states that the tool includes 'per-review rating, text, dealer reply and paging totals', which informs the agent of the response contents and that it supports paging (via 'paging totals'). It implicitly indicates a read operation ('Fetch') and does not mention any destructive or state-changing behavior. It does not explicitly state authentication or rate limits, but for a simple fetch with pagination, the disclosure 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 a single, well-structured sentence that front-loads the verb and resource ('Fetch a dealer's customer reviews'), then immediately clarifies the critical ID source and lists response contents. It is concise with zero wasted words, and the clarification is placed early to prevent misuse. The structure is efficient and informative.

  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 tool with three parameters and no output schema, the description provides a solid overview: it states the purpose, the required ID and its source, and the key fields returned (rating, text, dealer reply, paging totals). It also mentions paging, which aligns with the size/offset parameters. It does not detail the exact response structure (e.g., is it a list of objects?), but given the listing of contents, an agent can reasonably infer the return format. Minor gaps like error handling or edge cases are not critical for a fetch operation.

  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 input schema already documents all three parameters (dealerId, size, offset) with descriptions. The tool description adds context about dealerId's origin ('from get_watch's sellerIds'), but this is already present in the schema description ('Dealer id from get_watch's sellerIds (NOT the customerId)'). The description does not add new semantic value for parameters beyond what the schema provides, so baseline 3 applies.

  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 ('Fetch a dealer's customer reviews') and specifies the key identifier (dealerId) with a crucial disambiguation: it's from get_watch's sellerIds, not the customerId. This distinguishes it from other tools that might use similar IDs, and the mention of 'dealer ratings' implies the resource. It stands apart from siblings like get_dealer_listings or get_watch by focusing on reviews/ratings.

  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 on the correct source of the dealerId ('from get_watch's sellerIds - NOT the customerId'), which guides correct usage and prevents common misuse. It does not explicitly name alternative tools or state when not to use this tool, but the context about the ID source is a strong usage guideline. It implies usage for fetching reviews, and the clarification about ID origin is a form of usage guidance.

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

• list_brandsA
  4.3/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 clarifies that this is a read-only listing operation, states the output contains numeric ids, and gives a scale ('550+'), which helps set expectations. It does not mention pagination or response structure, but for a simple list endpoint these are not critical 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, no filler. The main purpose and output shape are front-loaded, and the second sentence gives actionable guidance without redundancy. Every clause contributes value.

  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 zero required parameters, a simple optional query, and no output schema, the description provides enough information to call it correctly and use its results effectively. It names the output format, scale, and integration points with sibling tools.

  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% because the query parameter is already fully documented as an optional case-insensitive substring filter with examples. The description adds context about how ids are used downstream but does not need to repeat parameter details already present in the 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 uses a specific verb ('List'), names the exact resource ('Chrono24 watch brands'), and states the output includes numeric ids with a scale ('550+'). It also distinguishes the tool from siblings by showing how the returned ids/names feed into search_listings and find_models.

  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 tells the agent how to use the result: pass an id to search_listings' manufacturerIds or a name to find_models. It does not explicitly state when list_brands should be chosen over alternatives, but because it is the only brand-listing tool among the siblings, the intended usage is clear.

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