Server Quality Checklist

Tool Scores

• list_structural_driversA
  4/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 for behavioral disclosure. It adds useful context about the domain (98 drivers, root causes, breaking one weakens many pain points) but does not disclose operational behaviors such as read-only nature, return format, pagination, or any side effects. The 'list or search' wording implies a safe read operation, but it is not explicit.

  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 resource, followed by a concise usage rationale. Every word earns its place—no fluff, redundancy, or irrelevant detail. It is an ideal length for quick agent parsing.

  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 simple list/search tool with no output schema, the description provides strong conceptual context and usage guidance. It explains what the tool does, why it matters, and when to use it. However, it does not describe the return format or result structure, which would be helpful given the absence of an output schema. Still, the overall coverage is solid for the tool's moderate complexity.

  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 three parameters (limit, query, track) with clear descriptions. The tool description does not add additional meaning about parameter semantics; it focuses on the overall purpose. Baseline of 3 is appropriate because the schema handles parameter explanation.

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

  Purpose5/5

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

  The description opens with 'List or search the 98 structural drivers', which is a specific verb+resource statement. It further explains that drivers are the root causes generating pain points, clearly distinguishing this tool from siblings like search_pain_points or search_faq. The purpose is unambiguous and well-scoped.

  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 when this tool is appropriate: 'the right unit for 'why does this keep happening' and 'what should we actually fix' questions.' This gives clear context for usage. However, it does not explicitly name alternative tools or when not to use it, so it misses the 'exclusions/alternatives' element.

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

• lookup_jurisdictionA
  4/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 clearly indicates a read-only lookup and specifies the returned content (DPA, legislation, links). However, it does not disclose behavioral nuances such as what happens when no jurisdiction matches, whether matching is case-sensitive, or any limitations on the region filter. 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?

  Two sentences, with the first front-loading the core action and scope ('Look up privacy-law status...') and the second giving concrete use cases. No redundant or filler content; every sentence 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 simple lookup tool with optional parameters and no output schema, the description covers the essential aspects: scope (240 jurisdictions), output content (authority, legislation, links), and typical use cases. It lacks details on response format or error handling, but overall it is sufficiently complete for an agent to select and invoke the 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 coverage is 100% with descriptive parameter explanations (e.g., 'country name or fragment'). The description adds the '240 jurisdictions' context and use cases but does not materially enhance parameter-level meaning beyond what the schema already provides. 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 uses the specific verb 'look up' and clearly identifies the resource: 'privacy-law status for a country or region across 240 jurisdictions'. It enumerates the output components (data protection authority, legislation, links), which distinguishes it from sibling tools focused on FAQs, pain points, research papers, etc.

  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 explicit use cases: 'Use for "is there a privacy law in X" and cross-border transfer questions.' This gives clear context for when to choose this tool over siblings, though it does not mention specific alternatives or when not to use it.

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

• search_faqA
  4/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 burden of behavioral disclosure. It adds useful context about the content (134 items, evidence-backed, each with root cause/example/data points), but it does not state whether the operation is read-only, how results are ordered, or any limitations. This is adequate for a simple search tool 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?

  Two concise sentences: the first states the primary action and content scope, the second gives usage guidance. There is no filler or redundancy, and the most important information is front-loaded.

  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 2 parameters, full schema coverage, and no output schema, the description sufficiently explains the content scope (134 items, evidence-backed) and expected item composition (root cause, example, data points). It falls short of 5 only because it doesn't explicitly describe the return format or edge-case behavior like empty results, but this is minor for a search 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?

  The input schema fully describes both parameters ('query' and 'limit') with clear descriptions, achieving 100% coverage. The tool description does not add any parameter-specific semantics, so the baseline score 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 opens with a specific verb ('Search') and identifies the exact resource ('134 evidence-backed privacy questions and answers'). It also outlines the content structure (root cause, real-world example, supporting data points), which distinguishes it from siblings like search_research_papers and search_pain_points.

  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 final sentence, 'Use for direct practitioner questions,' gives a clear when-to-use context. However, it does not explicitly mention alternative tools or when not to use this tool, so it falls short of the explicit 'when/when-not/alternatives' level.

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

• search_pain_pointsA
  4.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 results are concrete, evidenced problems tagged with research track, category, and severity, providing useful context beyond a generic search tool. It stops short of describing return format or potential limitations, but it is informative.

  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 exactly two sentences, front-loaded with the purpose, and includes examples and usage guidance without any filler. Every sentence contributes value.

  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 3-parameter search tool with no output schema, the description provides sufficient context: what is searched, how results are structured, and when to use it. Minor gaps like pagination or sorting are non-essential.

  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 3 parameters with descriptions (100% coverage), so the baseline is 3. The description adds general context about the corpus but does not add specific parameter-level semantics beyond what the schema already provides.

  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 ('Search') and identifies a concrete resource ('1,478 documented PII/privacy pain points'), with examples that clearly distinguish it from sibling tools like search_faq or search_research_papers.

  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 when to use the tool: 'Use for "what goes wrong with X" questions.' This is clear context, but it does not mention alternatives or exclusions, so it falls short of a 5.

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

• search_research_papersA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It adds context that the papers are 'real' and 'underpinning the research,' and lists searchable fields. However, it doesn't disclose behaviors like result ordering, handling of empty results, or read-only nature beyond what a search implies. 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?

  Two concise sentences with no fluff. The first sentence states the action and scope; the second gives usage direction. Information is front-loaded and easy to scan.

  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 simplicity (2 params, 1 required) and full schema coverage, the description provides robust context. It lacks an explicit return structure since no output schema exists, but the mentioned fields make results inferable. Nearly complete for a search tool.

  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?

  Schema covers both parameters (100%). The description adds value by specifying searchable fields 'title, authors, abstract, DOI,' which extends beyond the schema's claim of 'title and abstract.' This clarifies query scope and enriches parameter understanding.

  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 'Search 1,600+ real academic papers' with specific fields (title, authors, abstract, DOI), making the action and resource explicit. This distinguishes it from sibling tools like search_faq and search_pain_points, which target different content types.

  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?

  Provides explicit usage context: 'Use when a claim needs a citable primary source.' This clearly indicates when to select this tool. It does not explicitly mention alternatives or when not to use it, but the context is strong enough to guide selection.

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

• get_corpus_statsA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses the tool's read-only nature (returning counts and values) and adds useful context like 'data freshness.' It could explicitly state 'read-only' or mention absence of side effects, but the implied safe discovery purpose is fairly transparent for a zero-parameter stats tool.

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

  Conciseness5/5

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

  The description is two sentences, tightly focused, and front-loaded with the core action. The second sentence adds essential usage guidance without redundancy. 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 simple, parameterless tool with no output schema, the description is quite complete: it lists the main output categories (counts, filter values, data freshness) and explains its role relative to other tools. It could elaborate on data structure or format, but given the minimal complexity, this is sufficient.

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

  Parameters4/5

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

  The tool has zero parameters, and schema coverage is trivially 100%. Per the baseline for 0 params, the description adds no parameter-specific detail but also doesn't need to. It correctly focuses on the tool's output, which serves the discovery purpose.

  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 returns counts, available filter values (tracks, regions), and data freshness for the corpus. This specific verb+resource phrasing ("Return counts...") distinguishes it from sibling search tools, making its purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly instructs to call this tool 'first' to discover valid track and region values for other tools, providing clear when-to-use guidance. It implicitly excludes use for direct search/lookup since its role is discovery, which differentiates it from siblings.

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