Server Quality Checklist

Tool Scores

• scrape_with_jsC
  2.4/5.0
  Behavior1/5

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

  With no annotations, the description must disclose behavioral traits, but it only states the core function. There is no mention of headless browser nuances, asynchronous delivery, proxy behavior, retries, screenshots, or dependencies like 'returnJSON'. This is a significant omission for a tool with 35 parameters.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence and front-loaded, but it is under-specified. While concise, it fails to provide sufficient detail to be useful; it is a terse statement rather than a helpful summary. The brevity is not backed by meaningful content.

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

  Completeness1/5

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

  Given the tool's complexity (35 parameters, no output schema, no annotations), the description is grossly inadequate. It provides no context about return values, async behavior, limitations, or prerequisites. The agent cannot reasonably understand the tool's full scope from this description alone.

  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 fully documented in the schema. The description adds no extra semantic meaning, but with complete schema coverage, the baseline of 3 is appropriate. No parameter information is missing from the schema itself.

  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 scrapes JavaScript-rendered pages using a headless browser, which identifies the specific resource and action. It distinguishes from sibling tools like 'scrape' (likely static) and 'scrape_to_markdown' (formatting), though it doesn't explicitly name them.

  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 lacks exclusions or contextual cues, leaving the agent to infer usage from the name alone. The presence of sibling tools like 'scrape' suggests complementary use cases but is never addressed.

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

• scrape_to_markdownC
  2.6/5.0
  Behavior1/5

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

  No annotations are provided, and the description offers no behavioral transparency. It does not mention that the tool performs network requests, potential authentication needs, rate limits, or side effects. For a scraping tool, this is a significant disclosure gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The single sentence is concise and front-loaded, but for a tool with 22 parameters it is under-specified. It is not bloated, but it lacks structure and fails to add value beyond the basic purpose.

  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?

  The tool has high complexity (22 params, no output schema), and the description is incomplete. It states the output format (markdown) but gives no information about return values, error behavior, parameter interactions, or typical use cases. The required URL parameter is not mentioned in the 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 provides 100% coverage of all 22 parameters with descriptions, so the baseline is 3. The description adds no meaning beyond the schema, but it also does not contradict or omit anything the schema already covers.

  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 states the core action ('Scrape and convert to markdown format') with a clear subject (URL via required parameter). It differentiates from the sibling 'scrape' by specifying markdown output, though it does not explicitly name alternatives.

  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 siblings like 'scrape' or 'scrape_with_js'. There are no prerequisites, exclusions, or context about ideal use cases, leaving the agent to infer from the name alone.

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

• take_screenshotC
  2.8/5.0
  Behavior2/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 only states the basic function and does not mention critical behaviors such as JavaScript execution, retry logic, proxy usage, cookie handling, or return formats. The schema hints at these features, but the description itself adds no transparency.

  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 concise sentence that is front-loaded and free of fluff. It is appropriately sized for a simple purpose, though given the tool's complexity, a bit more detail would be helpful. Still, as far as conciseness, it scores well.

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

  Completeness1/5

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

  The tool is highly complex with 24 parameters, no annotations, and no output schema. The one-sentence description is grossly inadequate; it does not explain return values, usage scenarios, error conditions, or how the tool behaves. This is a significant completeness gap for such a feature-rich 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% for all 24 parameters, so the description is not required to explain parameters. Since the schema already documents each parameter with clear descriptions, the description adds no additional semantic value, but the baseline of 3 is appropriate.

  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 'Capture webpage screenshots' clearly states the action (capture) and resource (webpage screenshots), and it distinguishes itself from sibling scraping tools like scrape and scrape_with_js by focusing on visual capture. However, it lacks specificity about screenshot variants (full-page, element, etc.), which are only in the schema.

  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 offers no guidance on when to use this tool versus alternatives such as scrape_with_js or scrape. There is no mention of use cases, exclusions, or prerequisites. Users are left to infer from the name and schema that it is for screenshots, but the description does not explicitly clarify when it should be preferred.

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

• scrapeA
  3.6/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 of behavioral disclosure. It only says 'basic' and 'without JavaScript rendering', but does not explain response formats, default methods, proxy usage, retries, or other behaviors. This is insufficient for a tool with 29 parameters.

  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, concise sentence that is front-loaded and wastes no words. It effectively communicates the core purpose in minimal space, earning a perfect score for conciseness.

  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's complexity (29 parameters), lack of output schema, and no annotations, the one-sentence description is inadequate. It fails to explain return values, overall workflow, or what to expect from the tool, leaving the agent with insufficient context for correct invocation.

  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 no parameter-specific information beyond what the schema already provides, meaning it does not enhance parameter 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 'Basic web scraping without JavaScript rendering' clearly identifies the tool's function (web scraping) and its scope (no JS rendering). This directly differentiates it from the sibling tool scrape_with_js, making its purpose unambiguous.

  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 phrase 'without JavaScript rendering' implies this tool is for static pages when JS execution is not required, contrasting with scrape_with_js. However, it doesn't explicitly mention alternatives or when-not-to-use cases, so it falls short of fully explicit guidance.

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

• get_usage_statsA
  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. 'Get' implies a read-only operation, and it states the kind of data returned. However, it does not disclose any additional behavioral traits such as whether it consumes credits, rate limits, or response format.

  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, concise sentence that conveys the essential information without any wasted words. It is front-loaded and easy to parse.

  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 - no parameters, no annotations, no output schema - the description is reasonably complete. It states what the tool does and what information it provides. A bit more context (e.g., using it to check quota before scraping) would improve it, but it is sufficient for this low-complexity 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?

  The tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description correctly focuses on what the tool returns rather than input details.

  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: retrieving API usage statistics and remaining credits. It uses a specific verb ('Get') and resource ('API usage statistics and remaining credits'), and it is distinct from the sibling scraping tools.

  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 provides no explicit guidance on when to use this tool versus alternatives. While siblings are all scraping tools, making the distinction obvious, there is no stated context, prerequisites, or exclusions.

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