Server Quality Checklist

Tool Scores

• parse_sitemapA
  3.7/5.0
  Behavior3/5

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

  Without annotations, the description must carry the burden, and it does cover the core behavior: fetching a sitemap and returning count, sample, and nested sitemaps. However, it omits details like error handling, response size limits, or whether it follows redirects, which are relevant for a networked fetch 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?

  The description is a single, well-structured sentence that front-loads the action ('Fetch') and the key return elements. No redundant words or fluffy content.

  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 output schema, the description adequately summarizes the return values. It mentions URL count, sample entries with lastmod, and nested sitemaps. However, it could be more explicit about error conditions and the exact structure of the sample, but for a simple tool this is nearly complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not mention the parameters. 'sitemapUrl' is only inferred from 'Fetch a sitemap.xml or sitemap index', while 'sampleSize' is entirely absent. The description adds no meaning beyond the parameter names.

  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 uses specific verb 'Fetch' and resource 'sitemap.xml or sitemap index', clearly stating what it does. It distinguishes from siblings by focusing on sitemap-specific details (URL count, sample entries with lastmod, nested sitemaps), unlike extract_links or check_robots.

  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?

  Usage is implied rather than explicit: the description indicates when to use it (to parse a sitemap) but does not mention alternatives or exclusions. No reference to sibling tools like extract_links or check_robots, so the agent must infer context from the name.

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

• extract_linksA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the core behavior: splitting links into internal/external, counting nofollow, and optional HEAD-checks. However, it omits details like return format, pagination, or any rate limits or error behavior, leaving some transparency gaps.

  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 a single, well-structured sentence that front-loads the primary action and then adds the optional check behavior. Every word earns its place, with no fluff or redundancy.

  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?

  The tool is relatively simple, and the description covers its main behavior, but it lacks details about output format, the meaning of checkLimit, and any caveats around HEAD-checks. Given no output schema and no annotations, these gaps make the description adequate but not fully complete.

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

  Parameters2/5

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

  The schema has 0% description coverage, so the description must compensate. It adds meaning to checkBroken via 'Optionally HEAD-checks internal links,' but checkLimit is left unexplained in both schema and description. The url parameter is self-evident, but the incomplete coverage for checkLimit prevents a higher score.

  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's function: 'List a page's links split into internal and external with nofollow counts.' This is a specific verb and resource that distinguishes it from siblings like audit_page, extract_schema, check_robots, and parse_sitemap, which focus on other aspects.

  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?

  It clearly communicates that it can optionally HEAD-check internal links to find broken ones, giving a concrete use case. However, it does not explicitly contrast with sibling tools or state when not to use this tool, so it lacks full exclusions.

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

• audit_pageA
  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 burden. It discloses that it fetches a URL and returns data, but it does not mention potential side effects, error handling, redirects, or rate limits. The behavior is partially transparent but not deeply detailed.

  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 sentence but long, listing many output items. It is front-loaded with the main action and then enumerates details. While not overly verbose, it could be more structured (e.g., bullet points), so it earns a 4.

  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?

  With no output schema, the description must explain what the tool returns, and it does so by listing the specific SEO data fields. It lacks details on the response format or edge cases, but for a straightforward fetch-and-audit tool, it is reasonably 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?

  The schema covers the single 'url' parameter with type and format. The description mentions 'Fetch a URL' which effectively clarifies the parameter's purpose, but it adds no additional semantics beyond the schema. With only one parameter and 0% schema description coverage, it is minimally sufficient.

  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 a URL and returns structured on-page SEO data, listing the specific elements. This distinguishes it from sibling tools like extract_links or check_robots, which focus on different aspects.

  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 implies the tool is for on-page SEO auditing through its title and detailed list of SEO elements. It provides clear context but does not explicitly state when to use it over alternatives or mention exclusions, so it falls short of a 5.

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

• extract_schemaA
  3.9/5.0
  Behavior4/5

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

  With annotations absent, the description discloses that it extracts all JSON-LD blocks, lists @type values, and returns parsed objects with parse errors. This covers core behavior but does not address edge cases like missing JSON-LD or dynamic rendering.

  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 a single sentence that front-loads the action ('Extract every JSON-LD block') and then lists the outputs. No unnecessary 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 the simple single-parameter tool and lack of output schema, the description adequately lists the return contents (parsed objects and errors). It could be more specific about the response structure, but it is sufficient for basic understanding.

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

  Parameters2/5

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

  The only parameter 'url' has no description in the schema, and the description only indirectly refers to it via 'from a page'. It does not explain expected URL format, accessibility requirements, or how the URL is used beyond the general 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?

  Description states 'Extract every JSON-LD block from a page' with a clear verb and resource, and distinguishes itself from sibling tools like extract_links and parse_sitemap by focusing on JSON-LD structured data extraction.

  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 the tool is for extracting JSON-LD structured data, but it does not explicitly state when to use it over alternative tools (e.g., extract_links for links). No exclusions or alternatives are mentioned.

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

• check_robotsA
  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 the full burden. It explains the output content (user-agent groups, sitemaps, crawl-delay) but does not disclose edge-case behavior such as missing robots.txt, HTTP errors, or redirect handling. It adds some context but not comprehensive behavioral transparency.

  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 a single, well-structured sentence that front-loads the action ('Fetch') and lists the return values concisely. Every word contributes meaning without redundancy.

  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 tool's simplicity (one parameter, no output schema), the description sufficiently explains what it does and what it returns. It lacks details on potential errors or status codes, but for a direct robots.txt fetch-and-parse tool, the information is largely complete for an agent to use it correctly.

  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 schema covers the single parameter siteUrl with a clear description ('Any URL on the site'), so schema coverage is 100%. The tool description does not add further parameter semantics, but this is unnecessary since the schema is fully self-explanatory.

  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 a site's robots.txt and returns parsed data (user-agent groups, rules, sitemaps, crawl-delay), using a specific verb and resource. It unambiguously distinguishes itself from siblings like parse_sitemap and extract_links.

  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 implies the tool is for inspecting robots.txt rules, and the sibling tool names provide contextual alternatives (e.g., parse_sitemap for sitemaps). However, it does not explicitly state when not to use it or mention alternatives, so it falls slightly short of full guidance.

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