Server Quality Checklist

Tool Scores

• get_time_seriesA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the value range (0-100), volume availability, and explicit instruction to tell the user when rate limits or monthly quota are reached. No contradictions with annotations.

  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 compact and front-loaded: it states the core behavior first, then usage contexts, then exclusions with alternatives, then error-handling behavior. Every sentence adds unique value with no redundancy.

  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 rich input schema, output schema presence, and annotations, the description covers what an agent needs to select and invoke the tool correctly. It includes usage contexts, sibling alternatives, series characteristics, and quota/rate-limit handling. No important operational gap remains.

  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 both keyword and source already richly documented. The description mentions 'one keyword and one source' and the limit condition, but it does not add significant meaning beyond the schema's detailed per-source keyword formatting rules. Baseline 3 is appropriate because the schema carries the parameter burden.

  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 statement of what the tool returns: 'Full historical series for one keyword and one source (0-100 values, plus volume when available).' It clearly distinguishes this tool from siblings by naming what it is not for: live trending boards go to get_top_trends and most growth questions go to get_growth.

  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?

  Explicit when-to-use guidance is present: 'Use for charting or custom math.' It also gives direct exclusions with named alternatives: 'Not for live trending boards (use get_top_trends)' and 'For most growth questions, use get_growth.' This makes selection unambiguous.

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

• get_top_trendsA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds non-obvious behavior: category omission mixes every board, 'rank_change' compares against a prior snapshot with configurable windows, live store boards are not keyword lookups, and rate-limited/quota-exhausted requests should be reported as plan-limit reached. This is meaningful behavioral context beyond the structured hints.

  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 opens with the core purpose, then packs category rules, sort semantics, sibling routing, and rate-limit handling into one dense paragraph. Every sentence contributes, but the lack of visual structure makes it slightly harder to scan than necessary.

  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?

  With an output schema present, the description doesn't need to describe return values. It covers feed-type selection, category requirements, sort/window behavior, and sibling alternatives, plus edge-case handling for rate limits. There are no obvious gaps for an agent to call the tool correctly.

  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 coverage is 100%, with descriptions for type, sort, limit, offset, window, and category. The description adds value on top: it ties category to four specific types, warns that omitting it mixes boards, and clarifies that window only applies to rank_change and has daily/weekly/monthly nuances. That exceeds the baseline 3 for fully-covered schemas.

  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?

  States the tool is a 'Live top-trending board for exactly one feed type' and immediately distinguishes it from keyword lookups ('No keyword'). It also names the specific feed types and points to siblings for app history, so an agent knows exactly what this tool returns. The verb is implicit but the resource and scope are 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?

  Explicitly says 'For an app's history use get_growth or get_time_series...' and 'Do not use get_time_series for live boards,' naming the exact sibling tools and the condition that selects them. It also gives a hard rule for category feeds ('always pass category') and explains the exception for learning official names. This is clear when-to-use guidance.

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

• get_growthA
  4.9/5.0
  Behavior5/5

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

  Annotations already indicate read-only, idempotent, and open-world behavior. The description adds valuable non-annotation context: rate-limit/quota handling, the 0-100 value scale, absolute volume when available, and source-specific interpretation. No contradiction exists.

  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 compact and front-loaded with the core purpose, then covers windows, value scale, sibling routing, source caveats, and rate-limit response. Every sentence contributes distinct information without redundancy.

  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?

  With an output schema present and safety annotations provided, the description supplies the remaining essential context: growth semantics, preset windows, value scaling, source nuances, and how to respond on rate limits. Nothing needed to call the tool correctly appears missing.

  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 coverage is 100%, so the schema already documents sources, keyword formats, and growth windows. The description still adds value by emphasizing that app downloads/app rankings require an Android bundle ID and are not the App Store/Google Play live boards, but most parameter meaning already lives 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 states a specific verb and resource: point-to-point growth for a keyword on one or more sources. It explicitly contrasts itself with get_time_series and get_top_trends, so an agent can distinguish it from both siblings.

  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?

  It explicitly says 'Prefer this over get_time_series for growth questions', giving a clear routing rule. It also clarifies that app downloads and app rankings are not the live boards on get_top_trends, preventing a common misuse.

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