Server Quality Checklist

Tool Scores

• get_statsA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It does not disclose behavioral traits like auth requirements, rate limits, or read-only nature. The listed statistics give some idea of output but no side effects or safety info.

  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?

  Single sentence, front-loaded with key information. Every word contributes: verb (Get), resource (GapBase database statistics), specific outputs (total gaps, industry breakdown, trending gap count). No wasted text.

  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 zero-parameter, no-output-schema tool, the description is nearly complete. It covers the tool's purpose and data categories. However, missing details on output format, caching, or how results relate to sibling tools keep it from being fully comprehensive.

  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?

  There are no parameters, so the description cannot add parameter meaning. Baseline 4 is appropriate given 100% schema coverage and zero params; description correctly omits param 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 retrieves database statistics, specifying three distinct types (total gaps, industry breakdown, trending gap count). This verb-resource pairing is specific and distinguishes it from siblings like get_gap (single gap) or list_industries (industry list).

  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 overview statistics but provides no explicit guidance on when to use this tool vs alternatives. No exclusions or prerequisites are mentioned, leaving the agent to infer context from sibling names.

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

• get_gapA
  4/5.0
  Behavior3/5

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

  No annotations; description reveals return fields but no behavioral traits like idempotency, side effects, or rate limits. Adequate for a simple read operation.

  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, front-loaded with purpose, no fluff. Efficient 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?

  For a simple 1-param tool with no output schema, description covers purpose, usage, and return info. Lacks mention of possible error cases but overall complete.

  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% and parameter description already specifies id or slug. Description adds no new semantic meaning beyond what 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 a single gap by id or slug, returns specific details (problem, solution direction, blueprint URL), and is distinguished from siblings like search_gaps.

  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?

  Explicitly says 'Use after search_gaps' to get full details, providing clear context. Lacks explicit when-not-to-use or alternatives, but context is sufficient.

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

• search_gapsA
  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 full burden. It discloses the source of gaps (Reddit/LinkedIn/X) and the return format (problem statement, solution direction, blueprint URL). However, it does not mention any behavioral traits such as rate limits or pagination, so transparency is adequate but not exceptional.

  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, front-loading the primary purpose and then providing details on sources, industries, and return format. It is slightly verbose but stays focused and informative, with each sentence serving a purpose.

  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 lack of output schema, the description compensates by clearly stating return values: problem statement, solution direction, and blueprint URL. It covers all three parameters and lists sibling tools, making the context complete for the agent.

  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?

  Although the input schema already provides 100% coverage with descriptions, the description adds value by explaining the context of the query parameter (free-text search across pain points) and the industry filter. It also reinforces that leaving query empty allows browsing by industry, which is not explicitly 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 explicitly states it is the 'PRIMARY TOOL for finding startup ideas' and clearly specifies the verb 'search' and resource 'gaps'. It also distinguishes itself from siblings by describing its comprehensive database and direct relevance to user queries about ideas or opportunities.

  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 guidance: 'USE THIS TOOL FIRST for any query about ideas, gaps, pains, opportunities, what to build, or industry-specific problems.' It does not explicitly state when not to use, but the instruction suggests it is the first choice, effectively guiding usage.

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

• get_viral_social_gapsA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description bears full responsibility. It discloses output structure (5 gaps, peak windows in days/weeks) and implies read-only behavior. Lacks explicit statement of non-destructive nature or permissions but is sufficient for safe use.

  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?

  Front-loaded with 'SPECIALIZED TOOL' and bold usage restrictions. While somewhat lengthy, every sentence adds value. Minor redundancy in listing trigger words could be trimmed, but overall efficient.

  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 no parameters and no output schema, description adequately covers what the tool does, when to use it, and what it returns (5 gaps). Missing explicit output structure for agent processing, but sufficient for invocation decision.

  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?

  Input schema has zero parameters, so baseline is 4 per rubric. No parameter explanation needed; description doesn't cover parameters because there are none.

  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 explicitly states the tool returns 'time-sensitive consumer/viral trend gaps' and specifies exact trigger conditions (TikTok challenges, HBO premieres, viral formats). It clearly distinguishes from sibling tool `search_gaps` by contrasting the scope (viral/social vs serious business opportunities).

  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 on when to use ('only use when user asks for VIRAL...') and when not to ('DO NOT call for general queries'), and names the alternative tool (`search_gaps`) with its purpose.

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

• list_industriesA
  4.7/5.0
  Behavior4/5

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

  No annotations provided, but description accurately describes the read-only listing of industries and counts. Does not mention any potential side effects, but given the nature, none are expected.

  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, front-loaded with the action and followed by usage advice. No wasted words.

  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 zero parameters and no output schema, the description fully explains the tool's purpose and provides usage context, leaving no gaps for a simple listing 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?

  No parameters exist; schema coverage is 100%. Description adds value by specifying the exact output content (industries and gap counts).

  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?

  Description clearly states it lists the 7 industries and their gap counts, distinguishing it from sibling tools that handle individual gaps or searches.

  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 instructs to use this first to understand database coverage before searching, providing 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.