Server Quality Checklist

Tool Scores

• get_best_storiesA
  4.6/5.0
  Behavior5/5

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

  Discloses read-only, idempotent, unauthenticated nature, client-side caching for 60 seconds, throttling to 10 req/s with burst 20, and error handling for upstream failures. No annotations present, so description carries full burden and meets it comprehensively.

  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?

  Well-structured with purpose first, then behavioral details, then usage guidance. Slightly verbose but all sentences earn their place; 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 single parameter and presence of output schema, the description fully covers purpose, behavior, error handling, and usage differentiation. No gaps remain.

  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 (limit) with its own description. The tool description adds no further semantic detail beyond the schema, so 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?

  Explicitly states it fetches Hacker News beststories ranking and returns summaries. Clearly distinguishes from siblings by contrasting with get_top_stories (front-page rank) and get_new_stories (chronological rank).

  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?

  Provides explicit guidance: use for high-quality/popular stories beyond current front page. Names alternatives: search_stories for topic discovery, get_item_thread for comments.

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

• get_new_storiesA
  4.6/5.0
  Behavior5/5

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

  Given no annotations, the description fully discloses caching (60s in-memory), rate limiting (10 req/s burst 20), and error handling (upstream failures returned as tool errors). No contradiction 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.

  Conciseness4/5

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

  The description is well-structured with front-loaded purpose and comparisons, followed by behavior details. Every sentence adds value, though it could be slightly shorter without losing clarity.

  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 covers purpose, usage, behavior, and parameters thoroughly. The only minor gap (return summaries format) is likely filled by the output schema.

  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 one parameter (limit) that already has a description. The description adds no extra parameter info beyond what the schema provides, so 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 clearly states it fetches HN newest stories from the newstories ranking and returns summaries. It explicitly distinguishes from siblings like get_top_stories (front-page rank) and search_stories (keywords).

  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 says when to use (recency matters more than score/comment activity) and when not (use get_top_stories or get_best_stories for popularity signals). Also notes read-only, idempotent, unauthenticated nature.

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

• get_top_storiesA
  4.6/5.0
  Behavior5/5

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

  Since no annotations are provided, the description fully covers behavior: read-only, idempotent, unauthenticated, 60-second in-memory cache, 10 req/s throttling with burst of 20, error handling for upstream failures. No behavioral gaps remain.

  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 long but well-organized and front-loaded. Every sentence adds value given the lack of annotations. Minor verbosity but not excessive.

  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 a simple single integer parameter and an output schema present, the description covers behavior, caching, throttling, error handling, and usage guidance completely for the tool's 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?

  The only parameter (limit) has 100% schema coverage with default and range, so the description adds little beyond 'returns story summaries' context. 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?

  Clearly states it fetches Hacker News front-page/top stories from the public Firebase API and returns summaries. Explicitly distinguishes from siblings like search_stories and get_item_thread.

  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 use for 'top', 'front page', or currently popular stories, and lists alternatives (get_new_stories, get_best_stories, search_stories, get_item_thread) for other use cases.

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

• get_item_threadA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description fully covers traits: client caching, throttling, error handling (missing root 404, deleted/dead skipped), and truncation via maxChildren.

  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?

  Single sentence is efficient but dense; could be split for readability, but it packs significant 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?

  Given no annotations and an output schema, the description covers error scenarios, caching, throttling, and constraints, making it fully informative for agent usage.

  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 all parameters (100% coverage), but the description adds behavioral context like truncation and comment tree expansion, aiding understanding beyond schema details.

  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 fetches one Hacker News item by ID and expands its comment tree, distinguishing it from sibling tools like story-list and search_stories.

  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 contrasts with alternative tools ('unlike story-list tools or search_stories') and states when to use ('only when you already have an item ID'), along with noting read-only, idempotent, unauthenticated access.

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

• search_storiesA
  4.8/5.0
  Behavior5/5

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

  Discloses all relevant behavioral traits: read-only, idempotent, unauthenticated, client caching (60s), throttling (10 req/s burst 20), error handling, and behavior for empty/no-match queries. Since no annotations are provided, the description fully compensates.

  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 paragraph but every sentence adds value. It is concise relative to the amount of information conveyed. A structured list might improve readability, but it is not overly verbose.

  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 presence of an output schema (not shown but indicated), the description does not need to explain return values. It covers input constraints, behavior, error handling, and alternative tools, making it complete for an agent to use this 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%, so baseline 3. The description adds value by clarifying that query is sent verbatim and matching is token-based (not exact phrase), and that limit defaults to 10 with max 30. This is useful context beyond the schema descriptions.

  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 (searches by keyword), the resource (Hacker News stories via Algolia API), and the ranking method (relevance/popularity). It also distinguishes from sibling tools by noting when to use this tool versus story-list tools and get_item_thread.

  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 states when to use (topics or phrases) and when not to (use story-list tools for rankings, get_item_thread for comments). Also covers edge cases (empty query rejected, no-match returns empty array), providing clear guidance.

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