Server Quality Checklist

Tool Scores

• search_contentA
  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 of behavioral disclosure. It mentions that it returns snippets with context and line numbers, which clarifies the output format, but it does not disclose details about making network requests, potential side effects, or any limitations. The description is adequate but not rich in 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 two sentences, front-loaded with the primary action, and every word earns its place. It is concise yet informative, with no redundant or filler 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?

  The tool has 6 parameters and no output schema, but the description provides sufficient context: it explains the core functionality, gives a use case, and describes the return format (snippets with context and line numbers). However, it does not address the 'format' parameter or clarify the relationship with the sibling tool fetch_and_search, leaving minor gaps for a complex tool.

  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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning by mentioning 'URL (or raw HTML)', which aligns with the url and html params, but it does not add substantive detail beyond what the schema already documents. Thus, the description neither substantially improves nor harms parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/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: 'Search the content of a URL (or raw HTML) and return matching snippet(s) with surrounding context and line numbers.' This uses a specific verb and resource, and it distinguishes from fetch_url and extract_links, but it does not explicitly differentiate from the sibling tool fetch_and_search, which likely has a similar 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 provides context for when to use the tool: 'Useful to find specific text/code/errors on a page without reading the whole thing.' This gives clear usage context, but it does not mention alternative tools or when not to use this tool, so it lacks exclusions or explicit comparisons.

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

• fetch_and_searchA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the behavioral disclosure burden. It discloses the combined behavior (returning content, links, and snippets simultaneously) and the optional nature of pattern/links, but it does not mention potential side effects, network failures, rate limits, or whether the operation is read-only. This is a moderate level of transparency for a fetch 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?

  The description is three sentences long, front-loaded with the core purpose, and free of unnecessary details. Every sentence earns its place: the first explains what it does, the second gives usage context, and the third clarifies optional parameters. It is appropriately sized for the tool's complexity.

  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 has 9 parameters and no output schema, so the description should provide a coherent picture. It gives a high-level overview of outputs (content, links, snippets) but does not describe the output structure or how the results are combined. While the schema covers parameters, the lack of return format details leaves some gaps for an agent invoking this tool.

  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 description coverage is 100%, so parameters are already well-documented in the schema. The description adds minimal value beyond that, with only the note to 'omit pattern/links as needed' and the implicit indication that links and search are included by default. This satisfies the baseline but doesn't significantly enhance understanding.

  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: 'fetch a URL and simultaneously return BOTH the cleaned content AND its links AND any matching search snippets.' It uses a specific verb (fetch) and names the resource (URL) and the combined outputs, distinguishing it from sibling tools like fetch_url and search_content by highlighting its one-shot combo nature.

  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 explicit usage context: 'Most efficient when you want to understand a page and also navigate/search it.' It implies when to choose this combo over individual sibling tools, though it does not explicitly name alternatives or state when not to use it. The instruction 'Omit pattern/links as needed' offers additional practical guidance.

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

• fetch_imageA
  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 the full burden of behavioral disclosure. It discloses the base64 return format and optional compression, but it does not explain what happens when an image exceeds maxSizeKB and compress is false (rejection behavior), nor does it mention error handling. This is a partial disclosure, so a 3 is appropriate.

  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 three sentences, front-loaded with the core function, followed by the use case and the key feature. Every sentence contributes value and there is no redundancy or fluff.

  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 description covers the main purpose, the relative URL scenario, and the compression option. It is complete enough for a tool with a well-documented schema, though it could mention the rejection behavior for oversized images. Given the absence of an output schema, the base64 return is mentioned, which is important.

  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 describes all 7 parameters with 100% coverage, so the baseline is 3. The description adds a little context by mentioning compression in relation to oversized images and the relative URL use case, but it does not significantly expand on what the schema already 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?

  The description uses a specific verb ('Fetch') with a clear resource ('an image from a URL') and specifies the output format ('base64 image content'). It also includes a concrete use case with relative image URLs, effectively distinguishing it from sibling tools like fetch_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?

  The description explicitly states when to use the tool: 'Use when a page's markdown contains relative image URLs... and you need to view the image.' It provides clear context but does not explicitly list alternatives or when-not-to-use scenarios, so it doesn't earn a 5.

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

• fetch_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 full burden for behavioral disclosure. It reveals the Readability extraction behavior, default markdown output, and the impact of options like includeLinks and maxChars. This goes beyond minimal disclosure, though it omits potential error behaviors or rate limits, which are not essential for this simple 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?

  The description is two sentences with no redundancy. The first sentence states the core function and default behavior, while the second lists options and use cases. It is front-loaded with the key action and every clause contributes value.

  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 four-parameter tool with a fully described schema and no output schema, the description covers the operation, options, and ideal use cases. It does not address error handling or rate limits, but these are not critical for this tool's primary functions. The description is sufficiently complete to guide usage.

  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 description coverage is 100%, so the baseline is 3. The description mentions format options, includeLinks, and maxChars, but essentially restates what the schema already provides. It adds no new semantic meaning beyond the schema descriptions, so a 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 explicitly states 'Fetch a URL and return its main readable content as clean markdown by default (Readability extraction)', giving a specific verb ('fetch') and resource ('URL'), and clearly distinguishes from sibling tools by focusing on readable content extraction. This differentiates it from extract_links (link extraction), fetch_image (image fetching), and search_content (content search).

  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 explicit use cases: 'reading a web page, understanding a code/docs page, or getting article content without boilerplate.' It does not explicitly mention alternatives or when-not-to-use, but the context is clear enough to guide selection. The inclusion of sibling tool names in context also helps, but no direct comparison is made.

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

• extract_linksA
  4.3/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 the return structure (array of {href, text, ...}), mentions deduplication via grouping, and indicates support for raw HTML input. This adds meaningful behavioral insight beyond the schema, though it omits error handling and network behavior.

  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 action and return format, the second states the use case. It is front-loaded, concise, and contains no redundant text.

  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?

  Despite no output schema, the description lists the return fields, compensating well. The schema fully documents all six parameters. Combined, the description and schema provide complete understanding of tool usage, and sibling tools offer contrast.

  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 description coverage is 100% with each parameter explained. The description adds context about the two input modes but no new semantics beyond what the schema already provides. 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 uses a specific verb 'Extract' with a clear resource 'all hyperlinks from a URL (or raw HTML)'. It distinguishes from sibling tools like fetch_url and search_content by focusing on link extraction, not content retrieval or searching.

  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 with 'Great for discovering pages/anchors before fetching them', implying a discovery step before fetching. However, it does not explicitly state when not to use or name alternative tools, so it stops 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.