Server Quality Checklist

Tool Scores

• fetch_jsonA
  4.3/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does an excellent job disclosing behavioral traits. It explains chunking, retry logic, data duplication handling, and even instructs the AI to communicate chunking to users.

  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 longer than average but well-structured with numbered best practices. It front-loads the core purpose and then provides important detailed guidance. While not maximally concise, every sentence adds value given the tool's complexity.

  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 19 parameters, no output schema, and complex chunking behavior, the description covers initial requests, resumption, retries, and user communication. It lacks explicit error scenario details but is otherwise 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?

  Schema description coverage is 100%, so the baseline is 3. The description adds significant semantic value by providing best practices for using startCursor and contentSizeLimit, explaining the chunking system, and offering guidance on parameter ranges (e.g., 20KB-50KB).

  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 JSON file from a URL' with a specific verb and resource type. The tool name and description clearly differentiate it from sibling tools (fetch_html, fetch_markdown, etc.) which handle other formats.

  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 best practices for using parameters like startCursor and contentSizeLimit, but does not explicitly state when to use this tool versus alternatives. Usage context is implied by the name and first sentence, but 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.

• fetch_txtA
  4.3/5.0
  Behavior4/5

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

  With no annotations, description carries full burden. It discloses chunking behavior, cursor-based retrieval, potential data duplication/gaps, and system note handling. However, it does not mention side effects, authentication needs, or rate limits, though these are likely minimal 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?

  Description is front-loaded with purpose, followed by well-organized numbered best practices. Despite length, every sentence adds value given the tool's complexity (22 params, chunking system). No redundancy or waste.

  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?

  Covers core workflow and behavioral expectations thoroughly. However, lacks description of the output format/response structure (no output schema). Users would benefit from knowing what fields to expect (e.g., content, fetchedBytes, chunkId). Otherwise, complete for a fetch 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%, providing baseline of 3. Description adds significant value with best practices for startCursor, contentSizeLimit, and chunking, going beyond schema definitions. It contextualizes how parameters work together for optimal use.

  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?

  Description clearly states verb 'Fetch' and resource 'website', and specifies output as 'plain text (no HTML)'. It distinguishes itself from siblings like fetch_html by emphasizing plain text. However, it could more explicitly differentiate from fetch_plaintext if that sibling exists.

  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?

  Description provides extensive best practices with numbered items covering initial cursor setup, chunk sizing, retry logic, and user communication. This gives clear guidance on when and how to use the tool effectively, including handling large content.

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

• fetch_plaintextA
  4.7/5.0
  Behavior5/5

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

  Given no annotations, the description fully discloses critical behaviors: chunking system, cursor-based pagination, retry implications (data duplication/gaps), content size limits, and handling of system prompts. This level of detail compensates for missing annotations.

  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 with a numbered list and front-loaded purpose. Despite its length, each sentence adds value for a complex tool with 22 parameters. A slightly more condensed version could improve conciseness.

  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?

  For a tool with 22 parameters, no output schema, and nested objects, the description is remarkably complete. It covers pagination, chunking, error handling, parameter ranges, and user communication. The lack of output schema is mitigated by explaining the return type (plain text).

  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?

  While the schema covers all parameters (100% coverage), the description adds significant context beyond syntax: recommended ranges (20000-50000 for contentSizeLimit), chunking workflow (startCursor/fetchedBytes/chunkId interplay), and parameter interactions (extractContent with includeMetadata/fallbackToOriginal).

  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 'Fetch a website and return the content as plain text with HTML tags removed', specifying the verb, resource, and output format. It distinguishes from sibling tools like fetch_html and fetch_json by emphasizing plain text output.

  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 extensive best practices for using startCursor, contentSizeLimit, chunking, and retry logic. However, it does not explicitly contrast with alternative tools (e.g., 'use fetch_html for HTML content'), leaving some implicit differentiation.

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

• fetch_htmlA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses chunking behavior, cursor management, retry semantics, data duplication risks, and instruction to ignore system notes. Comprehensive coverage.

  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 paragraph with five bullet-pointed best practices. Front-loaded with purpose, each sentence provides unique value. No 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 22 parameters and no output schema, the description covers core usage patterns well but could briefly mention response structure or error codes. Still highly informative.

  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%, baseline 3. The description adds value by providing usage context for key parameters like startCursor (always set to 0) and contentSizeLimit (20-50KB), beyond schema descriptions.

  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 'Fetch a website and return the content as HTML', specifying the verb, resource, and output format. This distinguishes it from siblings like fetch_json, fetch_markdown, etc.

  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?

  Five explicit best practices guide when and how to use the tool, including initial cursor setting, content size limits, chunking, retry handling, and user communication. No exclusions needed.

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

• fetch_markdownA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses chunking behavior, retry implications (duplication/gaps), content splitting, browser mode usage, and system note prompts to ignore. This fully informs the agent of the tool's behavior.

  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 detailed but organized with a clear opening and numbered best practices. Each sentence serves a purpose, though it could be slightly more streamlined. Still, it is well-structured and front-loaded.

  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 22 parameters, no output schema, and complex behavior (chunking, browser modes, retries), the description covers usage, limitations, and user interaction. It explains system notes and handles large content gracefully, making it sufficiently complete for an AI 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?

  Schema coverage is 100% with good parameter descriptions. The tool description adds value beyond schema by providing recommended ranges (e.g., contentSizeLimit 20000-50000), initial cursor guidance, and caveats about retries. Slight extra context elevates it above 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 'Fetch a website and return the content as Markdown', specifying the verb (fetch), resource (website), and output format (Markdown). This distinguishes it from siblings like fetch_html (HTML), fetch_json (JSON), etc.

  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?

  The description provides explicit best practices covering initial requests (startCursor=0), content size limits (20000-50000), chunking usage, retry handling with duplication warnings, and user communication about chunked content. It gives actionable guidance for when and how to use the tool effectively.

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