Server Quality Checklist

Tool Scores

• pingB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It only states the purpose but does not disclose the return value (e.g., boolean, status message) or any side effects. As a simple ping, the agent needs to know what the response looks like to interpret the result.

  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, efficient sentence that conveys the tool's purpose without any wasted words. It is appropriately sized for a simple tool.

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

  Completeness2/5

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

  Given the tool has zero parameters, no annotations, and no output schema, the description is incomplete. It does not describe the return value or any error conditions, leaving the agent without essential information to use the tool effectively.

  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?

  There are no parameters, and schema description coverage is 100%, so the baseline score of 3 applies. The description adds no extra parameter information, which is acceptable given the absence of 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 clearly states the tool checks that the crawlee MCP server is running. This is a specific verb-check and resource-server, and it distinguishes itself from sibling tools like fetch_url, screenshot, and crawl, which perform actual data retrieval or actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not specify its role as a health check before other operations, missing an opportunity to clarify its usage context.

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

• fetch_urlB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavior. It states the output is clean markdown and hints at content extraction, but fails to mention error handling, timeouts, rate limits, or what happens with inaccessible pages. This is a significant gap for a web-fetching 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 concise sentences, front-loaded with the primary purpose, with no wasted words. Every sentence provides useful information.

  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 description is adequate for straightforward use cases but lacks details on failure modes, limits, or what constitutes 'clean markdown'. Given no output schema, more context on return value behavior would be helpful for completeness.

  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 a baseline of 3 applies. The description adds value by explaining render_js with concrete examples (SPAs, Twitter/X) and clarifying the speed trade-off, which enhances understanding beyond the schema. The extract_content parameter is not elaborated, but overall improvement is notable.

  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 fetches a web page and returns clean markdown, with a specific verb and resource. It hints at differentiation from siblings by mentioning JavaScript-heavy pages, but does not explicitly distinguish from fetch_multiple or screenshot, leaving some ambiguity.

  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 clear guidance on when to set render_js=true vs false, which is useful for parameter choice. However, it does not address when to use fetch_url over its siblings (fetch_multiple, screenshot, ping, crawl), so cross-tool selection guidance is missing.

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

• screenshotB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the basic operation and return format, omitting important details such as JavaScript rendering behavior, timeout policies, image dimensions, privacy/security restrictions, or whether dynamic content is captured. This leaves an agent uninformed about key side effects and constraints.

  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, short sentence that directly conveys the core functionality. It is not verbose and efficiently communicates the purpose. However, it could incorporate minimal additional context (e.g., output format clarity) without losing conciseness, earning a 4 rather than a 5.

  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 that there is no output schema, the description correctly mentions the return type (base64-encoded PNG). However, it lacks details such as image resolution limits, ability to capture dynamic content, error responses, or size constraints. For a simple 2-param tool, it is mostly adequate but not fully 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 description coverage is 100%, so the baseline is 3. The description does not add any additional semantic value beyond the schema's parameter descriptions (e.g., it does not clarify that 'full_page' captures the entire scrollable height). The existing schema descriptions are sufficient for understanding the two 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 clearly states the action ('Take a screenshot'), the target ('a web page'), and the return format ('base64-encoded PNG image'). It effectively distinguishes from sibling tools (fetch_url, fetch_multiple, ping, crawl) which are about raw content retrieval or connectivity rather than visual capture.

  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 does not explicitly state when to use this tool versus alternatives (e.g., 'Use this instead of fetch_url when you need the rendered page as an image'). Usage context is implied by the contrast with sibling tool names, but no explicit when-to-use or when-not-to-use guidance is provided.

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

• crawlA
  3.6/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 basic behavior (recursive crawling, output format) and hints at content extraction via extract_content. However, it omits important traits such as domain scope restrictions, robots.txt compliance, rate limiting, timeout behavior, and handling of external links. The description provides minimal behavioral context beyond what is already implied.

  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, well-structured with the main action first, then output format, then a focused usage hint. No fluff or redundancy; every sentence serves a purpose. It is front-loaded and easy to scan.

  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 complexity (7 parameters, no output schema) and the fact that schema coverage is 100%, the description covers the core purpose and output structure. It also highlights the distinguishing link_pattern parameter. However, it could be more complete by noting key parameters like max_pages or render_js, which affect behavior significantly. Still, the combination of description and well-documented schema provides a fairly comprehensive understanding.

  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 baseline is 3. The description adds slight value by explaining the output format and suggesting link_pattern usage, but it does not add meaning beyond the schema's own parameter descriptions. Each parameter is already clearly described in the schema with defaults and constraints.

  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 crawls a website by starting from a seed URL and following links across multiple pages, distinguishing it from sibling tools like fetch_url (single page) and fetch_multiple (specific URLs). It also explicitly describes the output format as an array of {url, title, content} objects, which provides concrete purpose clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  The description does not provide any guidance on when to use this tool versus alternatives like fetch_url or fetch_multiple. It only mentions using link_pattern to restrict crawling, which is a parameter usage tip, not a usage guideline. There is no mention of prerequisites, typical use cases, or when to avoid this tool.

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

• fetch_multipleA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description must fully disclose behavioral traits. It mentions parallel execution and per-URL error handling via the return structure ({url, content, error}). However, it does not mention rate limits, timeouts, auth requirements, or what happens if all URLs fail. The provided information 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?

  The description is two sentences, front-loading the core action and return format, and then adding a usage hint. Every sentence provides 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 tool has 2 parameters, no output schema, and no nested objects. The description covers the core purpose, parallel execution, return structure, and a usage context. It is largely complete for a tool of this complexity, though it could mention result ordering or URL validation behavior.

  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% (both parameters have descriptions in the input schema). The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

  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 action ('Fetch multiple URLs in parallel'), the resource (URLs), and the return format (array of objects). It distinguishes from sibling tools like fetch_url (single URL) and screenshot (visual capture) by specifying parallel bulk fetching.

  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 includes 'Useful for bulk research or comparison tasks,' which implies a usage context but does not explicitly state when to use this tool versus alternatives (e.g., fetch_url for single URLs, screenshot for images). No exclusions or prerequisites are provided.

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