Server Quality Checklist

Tool Scores

• get_top_hostsA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the burden. It only mentions the data source (Common Crawl) but does not disclose any behavioral traits such as rate limits, caching, return format, or whether the list is precomputed or dynamic. This is insufficient for a tool with no 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 two sentences: the first states the purpose, the second adds usage guidance. No extraneous information, front-loaded, and highly readable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (single parameter, no output schema), the description is adequate for basic understanding but lacks behavioral details and return format, which would be expected given the absence of annotations. It is minimally 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% for the single 'limit' parameter with description including default and max. The tool description adds no additional semantics beyond the schema, so 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?

  The description clearly states the verb 'Get' and the resource 'top-ranked hosts across the entire web (from Common Crawl)'. It distinguishes from sibling tools like check_domain, get_domain_info, etc., which focus on specific domains rather than a ranked 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 provides usage context ('useful for research, comparison baselines, or finding top players in a niche') but does not explicitly state when not to use or contrast with sibling tools. Guidance is implicit rather than comparative.

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

• get_domain_infoA
  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 full burden. It states the tool returns information (read operation) but does not explicitly disclose that it is non-destructive, safe, or any potential side effects. The behavior is implied but not detailed.

  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: first defines the action and output, second adds practical use case. No wasted words or repetition, well 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?

  Given the simplicity of the tool (1 parameter, no output schema), the description sufficiently covers purpose, output aspects, and use case. It could mention return format but is adequate for the agent.

  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%, so the parameter 'domain' is described in the schema. The description adds context by explaining the output ('sitemap-style info') but does not add new meaning to the parameter beyond 'Domain to inspect'.

  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 ('Get') and resource ('domain') and lists exact outputs (metadata, page count, content categories, structural info), clearly distinguishing it from siblings like check_domain and get_expired_domains.

  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 a clear use case ('Useful for on-page SEO audits.'), giving context for when to use the tool. However, it lacks explicit guidance on when not to use it or mention of alternative tools.

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

• get_expired_domainsA
  4/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 full burden. It discloses the output includes rank and backlink count, and implies the data is fresh ('today's', 'freshly-expired'). However, it does not cover rate limits, authentication needs, or what happens on empty results.

  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 the main action front-loaded. Every sentence adds value, no wasted words.

  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 output schema, the description provides a good summary of output fields (rank + backlink count) and use cases. It covers the main functionality but could mention error handling or data freshness explicitly.

  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 descriptions for both parameters. The description does not add additional meaning to the parameters beyond the schema, but it does hint at the date usage ('today's'). 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?

  The description clearly states the tool retrieves today's freshly-expired domains with real backlinks, specifying the exact resource and verb. It distinguishes from sibling tools (check_domain, get_domain_info, etc.) which focus on existing domains, not expired ones.

  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 identifies target users (domain investors, PBN builders) and use cases, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives.

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

• get_referring_domainsA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It states the tool lists domains sorted by authority and returns backlinks with anchor context and rank. However, it omits details on error handling, data freshness, pagination, or required authentication. This is adequate but not comprehensive.

  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: first states core function and sorting, second provides use cases. Front-loaded, no redundant information, 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?

  No output schema, but description explains return values (backlinks with anchor context and rank). Lacks details on pagination and error handling, but covers essentials. Sibling tools are distinct, so role is clear.

  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%, so baseline 3. Description adds minimal value beyond schema: limit default and plan-dependent max are already in schema; domain example is also in schema. No additional parameter context.

  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 verb 'list domains that link TO the target domain' and resource 'referring domains', with sorting by authority. It also explains output (backlinks with anchor context and rank), distinguishing it from siblings like check_domain or get_domain_info.

  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 when-to-use: 'when the user wants to see WHO links to a site, do competitor research, or find link-building opportunities.' No when-not-to-use or alternatives, but context is clear and siblings are non-overlapping.

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

• check_domainA
  4.3/5.0
  Behavior3/5

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

  No annotations provided, so description bears full burden. It reveals the data source (Common Crawl) and indexed size, which adds transparency. However, it does not mention rate limits, caching behavior, or data freshness—information that would be helpful for a read 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?

  Three sentences: action, output, usage guidance. No wasted words, front-loaded with purpose. Efficient and clear.

  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?

  Single required parameter with full schema coverage; output explained in description. No output schema needed as description lists returned fields. No omitted critical details for a simple authority check 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 coverage is 100% with clear description of domain parameter (stripping protocol/www). Description adds example values and clarifies cleanup behavior, exceeding what schema 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?

  Clearly states the tool checks backlink authority for a domain, listing specific metrics (DR, centrality, PageRank, referring domains). Distinguishes from siblings such as get_referring_domains (focused on backlinks) and get_domain_info (likely different info).

  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 advises usage when user asks about backlink profile, authority, or domain comparison. Does not provide when-not-to-use or alternatives, but the context is clear enough given the sibling list.

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