Server Quality Checklist

Tool Scores

• related_queriesA
  3.9/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 clearly explains the return format (a dict with 'top' and 'rising' keys, each containing records with 'query' and 'value'), and crucially elaborates on the 'rising' value, including the important caveat that a value of 5000% represents a 'Breakout' marker, not an actual 5000% increase. This is valuable context beyond a basic summary. It doesn't cover error handling or side effects, but as a read-only operation it adequately explains expected 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?

  The description is well-structured: a one-sentence summary, followed by an Args section and a Returns section. Every sentence adds value, and the critical note about the 5000% Breakout marker is front-loaded in the Returns section. There is no redundancy or filler, making it concise 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?

  For a tool with 3 parameters and no output schema, the description covers both parameter semantics and return structure in detail. It lacks explicit usage guidance (covered in dimension 2) and doesn't mention potential pitfalls like geo-specific limitations or timeframe formats beyond the example, but it gives enough for an agent to call it correctly. The inclusion of the Breakout marker is a nice completeness touch. It earns a 4 because it doesn't explicitly address how this relates to sibling tools.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must explain all parameters, and it does so thoroughly. Each parameter is described with its type and purpose: 'keyword: a single search term,' 'timeframe: pytrends timeframe string, e.g. "today 12-m",' and 'geo: ISO country code (e.g. "IN"), or "" for worldwide.' It gives examples and edge cases (empty string for worldwide), which is exactly what an agent needs.

  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 clear purpose: 'Top and rising related search queries for a single keyword.' It specifies the verb (retrieve/list), the resource (related search queries), and the scope (for a keyword). It differentiates from sibling tools by focusing on queries rather than topics, though it doesn't explicitly name an alternative. The purpose is clear enough for an agent to understand 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 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 its siblings like related_topics or interest_over_time. It doesn't state conditions such as 'use when you need related queries, not topics.' The only hint is the phrase 'related search queries,' which implies a distinction, but there is no explicit 'when to use' or 'when not to use' guidance. This is a noticeable gap.

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

• trending_nowA
  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. It describes the return format (list of strings), ordering (by trend rank), and typical size (~20). It does not mention read-only status or any error behavior, but for a trending fetch this is likely safe. The description adds useful behavioral context beyond the bare schema, though it could be more explicit about side effects or limitations.

  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 well-structured with an Args and Returns section, and the purpose is front-loaded in the first sentence. It conveys necessary information without unnecessary fluff. The format is standard 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?

  For a simple tool with one parameter, no output schema, and no annotations, the description covers the purpose, parameter semantics, and return shape. It mentions typical size and ordering, which is helpful. Missing details like error handling for invalid geo are minor and not critical for selecting/calling the 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?

  The schema has zero description coverage for the geo parameter, so the description must compensate. It does so by specifying the format (full lowercase country name), providing examples, and explicitly stating it is not an ISO code, which is crucial for correct usage. This goes beyond simply naming the parameter and gives actionable guidance.

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

  Purpose5/5

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

  The description clearly states it provides 'Today's top trending searches for a country' with specific verb and resource. It also distinguishes itself from sibling tools by explicitly noting the geo format differs from the other 4 tools. This makes it easy for an agent to select the right tool.

  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 gives context about what the tool returns but does not explicitly state when to use it over alternatives (e.g., when you need trending terms vs. interest over time). The note about geo format is a parameter hint, not a usage recommendation. Usage is implied but not clearly scoped with exclusions.

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

• interest_by_regionA
  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 behavioral burden. It discloses the return shape (list of records with geoName and keyword column), explains the 0-100 relative scale, and notes that values are region-relative. This gives an agent a concrete expectation of the output's meaning. It does not mention side effects, but as a 'search' operation it is implicitly non-mutating. This level of disclosure is solid for a read-only retrieval tool.

  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 well-organized docstring with a purpose line, Args section, and Returns section. It avoids fluff, and the key scoping constraint is front-loaded. It is slightly longer than strictly necessary (e.g., repeating the 0-100 scale), but every sentence adds useful information, so it 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 tool with 3 parameters, no output schema, and no annotations, this description is quite complete. It covers parameter formats, return structure, and the meaning of the interest scale. One minor gap is that for a worldwide geo, it is not explicitly clarified that records will be per country rather than per state/region, but this is a minor ambiguity given the phrase 'state/region within the specified geo.'

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

  Parameters5/5

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

  Schema coverage is 0%, and the description fully compensates. It defines 'keyword' as a single search term, 'timeframe' with an example format, and 'geo' with ISO code and 'worldwide' option, plus a default. All three parameters are explained beyond the schema, which only lists names and types. This is exemplary.

  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 opening sentence clearly states the action ('Search interest for a keyword') and the resource/scope ('broken down by state/region within the given geo'). This distinguishes it from siblings like interest_over_time (time series) and related_queries/topics (associations). The purpose is unambiguous and actionable.

  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 a use case (regional breakdown of interest) and provides parameter constraints, but it does not explicitly mention when not to use this tool or name alternative tools. It says 'within the given geo' which hints at context, but there is no direct comparison to siblings. Thus, usage guidance is implied rather than explicit.

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

• interest_over_timeA
  4.4/5.0
  Behavior4/5

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

  The description discloses important behaviors: it notes that only the first 5 keywords are used and additional ones are silently dropped, and it explains the 'isPartial' field indicating incomplete time periods. Since no annotations are provided, the description carries the full burden and adequately covers these behavioral nuances. It does not address rate limits or authentication, but for a read-only tool this is acceptable.

  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 well-structured with clear Args and Returns sections, front-loads the core purpose, and uses concise bullet points. Every sentence adds information, such as the maximum keyword count and return fields, without unnecessary filler.

  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 there is no output schema and no annotations, the description compensates by fully specifying the return format (date, isPartial, numeric per-keyword values) and parameter constraints. It provides everything an agent needs to call the tool correctly, including examples and edge cases, making it contextually complete.

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

  Parameters5/5

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

  The schema has minimal descriptions (0% coverage), but the description adds extensive semantic detail: keyword limit and silent drop behavior, example timeframe formats, and the meaning of an empty geo string. This far exceeds the bare schema, making parameter semantics highly clear.

  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 relative Google search interest (0-100) over time for up to 5 keywords compared side by side. This is distinct from siblings like related_queries or interest_by_region, which focus on different dimensions. The specific verb and resource make the 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 Guidelines3/5

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

  The description presents a clear context (temporal interest comparison) but does not explicitly state when to use it over sibling tools. It provides parameter details but no guidance on selecting this tool versus related_queries or interest_by_region. The intended use is implied by the description, not explicit.

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

• related_topicsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the exact return structure (dict with 'top' and 'rising' lists) and explains the 'value' field semantics (0-100 relative interest, and the crucial 5000% breakout marker). It also clarifies that topics are grouped into clusters, not raw queries. It does not cover error cases or rate limits, so a small gap remains.

  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 well-structured with Args and Returns sections, front-loading the main purpose. It is moderately sized but every sentence adds value, especially the breakout marker caveat. It could be slightly more concise, but the extra detail is important for correct interpretation of results.

  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 lack of an output schema, the description provides a complete picture of the return value, including field names and value interpretations. All parameters are covered, and the key caveat about 5000% is included. Missing minor details like potential error codes, but for a read-only data retrieval tool, it is sufficiently complete for correct usage.

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

  Parameters5/5

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

  Schema coverage is 0%, but the description fully explains all three parameters: keyword, timeframe (with example format), and geo (with example codes including worldwide). This completely compensates for the lack of schema descriptions, giving the agent everything needed to construct valid arguments.

  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 resource (related topics), the operation (top and rising), and the scope (for a single keyword). It explicitly differentiates from raw query strings, which is a key distinction from the sibling tool related_queries. This makes the purpose unambiguous and easily distinguishable.

  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 gives clear context for when to use it ('for a single keyword') and provides example parameter values (timeframe, geo). It implies the difference from related_queries by noting 'Google's topic clusters, not raw query strings', but does not explicitly name alternatives or state conditions for choosing this over siblings. Still, the usage is well implied.

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