Server Quality Checklist

Tool Scores

• read_and_scoreA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions read-only intent ('Read any URL') and output ('clean Markdown and the AIO accuracy score'), but it does not disclose caching behavior despite the 'fresh' parameter, potential delays, error handling, or security considerations for reading arbitrary URLs.

  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 long, front-loaded with the primary purpose (read and return Markdown and score), followed by a concise rationale for why this is the default. Every sentence adds value with no fluff or repetition of schema details.

  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?

  For a simple two-parameter tool, the description captures the main purpose and output. However, it omits any details about the AIO accuracy score's meaning, possible error cases, or how to use the 'fresh' parameter. The description is adequate but leaves room for clarification on edge cases and expected return payload structure.

  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 input schema has 100% parameter coverage, with descriptions for both 'url' and 'fresh'. The tool description adds no parameter-specific semantics beyond the schema, so the baseline score of 3 is appropriate. It does not explain how 'fresh' affects the call or when to set it true.

  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 combines reading a URL and scoring it in one call: 'Read any URL and return both clean Markdown AND the AIO accuracy score'. It distinguishes itself from siblings by explicitly positioning itself as the combined alternative to dedicated read_url and score_url tools.

  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 provides a clear usage recommendation: 'The recommended default for most AI workflows'. This implies that for workflows needing both content and quality, use this tool, while single-purpose needs might use siblings. However, it does not explicitly state when NOT to use it or mention alternatives by name.

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

• extract_dataA
  4.2/5.0
  Behavior4/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 key traits: deterministic ('no AI'), scoped to existing data ('only data present in the page'), and lists data types extracted. It does not mention caching behavior or error handling, which prevents a 5.

  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: the first front-loads the core function with specific data types, the second provides the use case and deterministic guarantee. No fluff or redundant language.

  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?

  The tool is simple with 2 parameters and no output schema. The description covers input, output scope, and deterministic behavior. It could mention the return structure or caching effects, but overall it is adequate for an agent to select and invoke the tool 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?

  Schema coverage is 100% for both parameters (url and fresh), so the schema fully documents them. The description adds no additional parameter semantics beyond the schema, earning the baseline score of 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 uses the specific verb 'extract' and names the resource: structured data a page already declares (JSON-LD, OpenGraph, meta tags) plus the AIO trust score. It distinguishes itself from sibling tools like read_url or score_url by focusing on structured data extraction and deterministic behavior.

  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 explicitly states when to use this tool: 'Use for fast, reliable facts (prices, products, articles) when the site publishes structured data.' This implies when not to use, but it does not name alternative tools or 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.

• map_siteA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that the tool does not read the pages ('without reading them'), reveals the sitemap-first strategy and fallback to on-page links, and notes performance ('Fast and cheap'). This gives the agent a good understanding of what the tool does and its non-intrusive nature, though it could further clarify return format or potential side effects.

  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 compact two-sentence structure that front-loads the core purpose, then adds usage guidance and performance notes. Every sentence earns its place with no fluff or redundancy. It is optimally concise.

  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 2-parameter tool with no output schema, the description covers the core behavior, method, and use case. It does not explicitly describe the return format (e.g., a list of URL strings), but that is inferable. The absence of error handling or edge case descriptions is minor given the simplicity, making this a highly complete description.

  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 input schema covers 100% of parameter descriptions (url and limit), so the description doesn't need to repeat them. The description adds no additional parameter-related context beyond what the schema provides. Baseline 3 is appropriate since schema covers all parameters.

  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 the specific verb 'Discover' with a clear resource ('a site's URLs') and method ('from sitemap.xml, falling back to on-page links'). It distinguishes itself from siblings like read_url and score_url by emphasizing non-reading and planning for crawling. This is a specific and unambiguous purpose.

  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 states a clear use case: 'use it to plan which pages to read or crawl next.' This provides context without explicitly naming alternative tools. It implies when to use this tool (as a planning step) but lacks explicit 'when not to use' or named alternatives, so it falls shy of a 5.

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

• read_urlA
  4.2/5.0
  Behavior4/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 that HTML noise is stripped, semantic content is preserved, and output is optimized for AI consumption. It implies read-only behavior and describes the transformation, adding useful context beyond the schema.

  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 the action and purpose, then efficient elaboration on behavior and intended use. 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?

  For a simple tool with two parameters and no output schema, the description provides enough context: what it does, how it transforms content, and when to use it. It does not mention caching behavior (though the 'fresh' parameter hints at it), but overall it is sufficient.

  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 description coverage is 100%, so the parameters (url and fresh) are already well-documented. The description does not add parameter-specific details beyond the schema, so a 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?

  The description uses a specific verb ('Read') and resource ('any URL') and clearly states the output format (Markdown). It distinguishes itself from sibling tools like score_url, map_site, batch, and extract_data by focusing on content extraction and conversion, not scoring, mapping, batching, or 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use: 'when you need to extract content from a website for an AI agent to process.' This provides clear context, though it does not mention alternatives or exclusions, which would make it more complete.

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

• score_urlA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the return type (0-100 score plus a list of penalties, benefits, and recommendations) and the underlying purpose (evaluating AI-readability). It implies a safe read-only operation ('Get') and adds context about the score's meaning. It could mention URL accessibility or error handling, but the core behavior is well disclosed.

  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 clean sentences. The first sentence front-loads the core purpose and output, the second immediately gives the usage context. No filler or redundancy—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?

  For a simple single-parameter tool with no output schema, the description covers essential aspects: what it does, what it returns, and when to use it. It explains the return structure in enough detail for an agent to understand the output. It doesn't address error cases (e.g., invalid/unreachable URLs) or prerequisites, but given the low complexity, the description is nearly 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 already provides full coverage for the only parameter: 'url' is described as 'The URL to score.' The description adds minimal extra meaning beyond confirming the URL is what gets scored, and it doesn't specify format restrictions or examples. Since schema coverage is 100%, a 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?

  The description clearly states the tool's function: 'Get the AIO (AI-readability) score for any URL.' It specifies the resource (URL) and the action (get score), and distinguishes itself from siblings like read_url by focusing solely on scoring. It also previews the output (0-100 score plus penalties/benefits/recommendations), making the purpose unmistakable.

  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 usage context: 'Use this to evaluate source quality before relying on it.' This tells the agent when to invoke the tool. While it doesn't explicitly name alternatives or exclusions, the context differentiates it from read_url or read_and_score by implying that scoring alone is sufficient for quality evaluation. A minor gap is not mentioning when not to use it, hence 4.

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

• batchA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It goes beyond a bare statement by disclosing billing behavior ('billed as one request'), the exact semantics of each mode, sitemap auto-discovery for 'site', and the default/max limits. It does not mention error handling or output format, but covers the key behavioral traits relevant to invocation.

  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 four sentences, front-loaded with the core value proposition, and every sentence adds critical information: billing, input options, mode details, and use case. There is no filler or repetition.

  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 tool with 4 parameters, no annotations, and no output schema, the description is remarkably complete. It explains purpose, usage, mode outputs, limits, and typical use cases. It does not detail the return structure or error conditions, but those are reasonable omissions given the tool's straightforward nature and absent output schema.

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

  Parameters5/5

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

  Even though the schema already has 100% coverage, the description significantly enriches parameter understanding. It clarifies that 'urls' and 'site' are mutually exclusive, explains how 'mode' maps to different output types, and specifies that 'limit' applies only to site mode with default 25 and max 50—all beyond 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 opens with 'Process many URLs in ONE call,' clearly stating the tool's batch-oriented purpose. It further distinguishes itself from siblings by highlighting the billing advantage and listing distinct modes, making it unmistakable from single-URL tools like read_url or score_url.

  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 explicitly says 'Use this for full-site reads or bulk URL processing,' providing clear context for when to choose this tool. However, it does not explicitly name single-URL alternatives or state when not to use it, leaving the exclusion implicit rather than explicit.

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