Server Quality Checklist

Tool Scores

• screenshotB
  3.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. It adds useful behavioral context: a 5-credit cost and a note that binary bytes aren't returned as text (only image metadata). However, it doesn't disclose error handling, rate limits, or the exact return structure, leaving gaps for an agent.

  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 concise sentences: purpose, cost, and a critical behavioral caveat. Every sentence earns its place, and the most important information (what the tool does) is front-loaded.

  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?

  This tool has 8 parameters and no output schema, yet the description only vaguely mentions 'reports image metadata'. It does not describe the returned data structure (e.g., base64, URL, JSON fields), error scenarios, or how to handle the result, leaving an agent under-informed 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?

  The input schema already documents all 8 parameters with descriptions (100% coverage). The tool description only recaps some parameter capabilities in prose, adding minimal value beyond the schema, so 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 opens with 'Capture a screenshot of a URL via the Scrapingdog Screenshot API (/screenshot)', using a specific verb and resource. It lists supported features (full-page, viewport, wait-until, format, quality) which clearly distinguishes it from sibling tools like scrape or search.

  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 such as scrape or search. The use case is implied by the tool's name, but there are no stated context cues, prerequisites, or exclusions.

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

• x_profileA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that it returns JSON with specific fields, but it does not mention the dependency on Scrapingdog API key, rate limits, caching behavior, or whether it performs a live scrape. These are significant omissions for an external scraping 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, front-loaded with the action and endpoint, and contains no filler. Every word contributes to understanding the tool's function.

  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 read-only scrape with only two parameters, the description adequately covers purpose, input format, and return fields. However, it omits mention of API key requirements or error conditions, and with no output schema, it relies on the listed fields to convey the response shape. Still, it provides enough context for an agent to select and invoke the tool correctly in most cases.

  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 3 applies. The description restates that the tool accepts a username or user ID, which is already in the schema's profileId description. It adds no new semantic detail beyond what the schema already documents.

  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 'Scrape' with a clear resource 'X (Twitter) profile' and even names the endpoint '/x/profile'. It distinguishes the tool from siblings like x_post and search tools by focusing on profile metadata.

  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 a parameter-level instruction ('Pass a username or user ID') but gives no explicit guidance on when to use this tool versus alternatives. The use case is implied by the resource, but no exclusions or comparisons with sibling tools are offered.

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

• baidu_searchA
  3.7/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 transparency burden. It does disclose that calls go through Scrapingdog and that results are returned as parsed JSON, and it highlights key options. However, it omits authentication requirements, rate-limit or cost implications, and behavior when the 'html' parameter is true.

  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 concise sentences that front-load the core action and return format, then list the important supported options. There is no fluff or repetition, and every sentence earns its place.

  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 search tool with a fully documented input schema, the description is mostly adequate. However, because there is no output schema and no annotations, it only vaguely promises 'parsed results as JSON' without describing the structure of those results or error behavior, making it complete enough but not thorough.

  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 already documents all six parameters with 100% coverage, so the baseline is 3. The description adds little beyond restating that ct handles Chinese-language restriction, pn handles pagination, and rn handles result count—details already present in 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 a specific verb 'Run' and clearly identifies both the tool ('a Baidu search') and the implementation endpoint ('via Scrapingdog (/baidu/search)'). It also states the return type ('parsed results as JSON') and the tool's name distinguishes it from sibling search engines like google_search and bing_search.

  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 implies the tool is for Baidu searches, but it does not explicitly contrast it with sibling tools such as google_search, bing_search, or duckduckgo_search. It provides no alternative recommendation, exclusion criteria, or conditions for when Baidu should be used over other engines.

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

• scrapeA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries full responsibility. It discloses the return type (HTML), core capabilities, and credit costs, which is useful behavioral context. However, it omits potential failure modes, rate limits, or whether the operation has side effects on the target site, leaving some gaps.

  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 concise, with the core purpose in the first sentence and capability/cost summary in the second. It is front-loaded and every sentence contributes, though the second sentence is a bit of a list and could be more structured.

  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 complex tool with 10 parameters and no output schema, the description adequately states the primary output (HTML), key features, and credit costs. It does not explain error handling or response structure beyond HTML, but the rich schema covers parameter details, making this reasonably 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 schema already documents every parameter's meaning, including credit costs for country and dynamic. The description provides only a high-level summary of supported features, adding no meaningful details beyond what the schema already offers. 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 clearly states it scrapes any URL via the Scrapingdog API and returns the page's HTML, using the specific verb 'Scrape' and resource. It inherently distinguishes itself from sibling tools like screenshot (captures images) and search tools (return search results).

  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 implies general-purpose scraping for any URL and lists key capabilities (JS rendering, proxies, geotargeting) that indicate when to use specific options, but it does not explicitly contrast with sibling tools or state when not to use this tool. No alternatives are named.

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

• x_postA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the transparency burden. It adds the endpoint path and that the ID comes from the post URL, but it does not describe the return format, error behavior, rate limits, or side effects. For a scraping tool, the read-only nature is implied but not explicit.

  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 concise sentences, front-loads the primary purpose, and wastes no words. Every sentence contributes useful information for selecting and invoking the tool.

  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 is simple with one required parameter and clear schema coverage, but there is no output schema and the description does not mention what the response contains. Since the tool's purpose is scraping, the agent can infer it returns post data, but error and output behavior are unspecified. The description is 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%, with both api_key and tweetId already well described in the input schema. The description's instruction to pass the numeric tweet ID merely echoes the schema example and adds no new parameter semantics beyond what the schema 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 ('Scrape') and resource ('X (Twitter) post (tweet)') and names the exact endpoint (/x/post). It clearly distinguishes from siblings like x_profile, which targets profiles, and generic scrape.

  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 clearly indicates that the tool is for scraping a single post and instructs the user to pass the numeric tweet ID from the URL. It does not explicitly mention alternatives or exclusions, but the context is clear enough for correct selection.

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

• bing_searchA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden but only discloses that it returns parsed JSON and uses Scrapingdog. It does not mention auth requirements (e.g., requiring an API key), rate limits, error behavior, or that parameters like count may vary. This is adequate but lacks rich behavioral context.

  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 no waste. It effectively covers the tool's purpose, key capabilities, and return type in a compact form.

  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 10 parameters and no output schema, the description is reasonably complete by summarizing the tool's scope. However, it does not detail the exact structure of the JSON response or mention operational aspects like API key handling, which the schema partially covers via the api_key parameter. It could be more precise about pagination semantics, but the schema descriptions fill most gaps.

  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% with detailed parameter descriptions, so the baseline is 3. The description adds a concise summary of features (market/country, geo, pagination, safe-search) that maps to existing parameters but does not introduce new meaning 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 clearly states the tool runs a Bing search via Scrapingdog, returning parsed JSON results. This distinguishes it from sibling search tools (google_search, duckduckgo_search, baidu_search) with a specific verb and resource.

  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 context on supported capabilities (market/country targeting, geo, pagination, safe-search) but does not explicitly say when to use Bing over alternatives or when not to use it. No exclusions or alternative naming, but the purpose is clear enough for basic selection.

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

• duckduckgo_searchA
  4/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 disclosure and does well by stating it returns parsed results as JSON, supports region/date filters, and has pagination with 15 results per page. It also mentions the Scrapingdog endpoint, adding context beyond the schema. It does not cover failure modes or rate limits, but provides solid behavioral context.

  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 only two sentences yet packs all essential information: what it does, the output format, and supported features. It is front-loaded and every word adds value with no redundant phrasing.

  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 is largely complete for a search tool, covering input capabilities and output format. However, there is no output schema, so the exact structure of the parsed results is not specified (e.g., whether it returns a list of results with title, URL, snippet). It also does not mention error handling or API key requirements beyond what the schema implies. Still, the core use case is well covered.

  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 each parameter is already well-documented. The description adds minimal extra meaning beyond repeating kl, df, and next_page_token, though it does add the pagination page size (15 per page) not present in the schema. This does not significantly improve semantic understanding beyond 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 clearly states the tool performs a DuckDuckGo search via Scrapingdog, with a specific endpoint and output format. It distinguishes itself from sibling search tools by explicitly naming DuckDuckGo and mentioning key capabilities like region, date filtering, and pagination.

  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 implies usage for DuckDuckGo searches but does not explicitly contrast with alternatives such as google_search, bing_search, or baidu_search. It lacks clear when-to-use / when-not-to-use guidance or any mention of alternatives, leaving the agent to infer based on the tool name alone.

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

• datacenter_proxyA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the tool doesn't make requests itself ('point your own HTTP client'), reveals the proxy endpoint, and mentions the output includes examples. It doesn't discuss auth or rate limits, but for a simple info-return tool this is sufficient.

  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 core function, then the proxy context, then optional behavior. No filler, 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 tool with two optional parameters and no output schema, the description gives purpose, output type, proxy nature, and optional parameter behavior. It lacks an explicit return structure but that is not essential for selection and 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?

  The input schema fully documents both parameters (100% coverage). The description adds some value by explaining target_url yields a ready-to-run curl, but does not mention api_key override. Baseline 3 applies since the schema already conveys parameter meaning.

  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 returns Scrapingdog Datacenter Proxy connection details (host, port, username, password) and ready-to-paste examples, with a specific proxy address. It explicitly contrasts with an HTTP API, distinguishing it from 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 Guidelines4/5

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

  It explains this is a forward proxy, not an HTTP API, which implies when to use it (to get proxy connection info) vs sibling tools (for direct scraping). It also notes the optional target_url behavior for a ready-to-run curl, but doesn't explicitly name alternatives or state when not to use.

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

• google_searchA
  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 the output format (JSON or raw HTML via html=true), mentions the credit cost (5–10 credits), and notes the underlying provider (Scrapingdog). These are meaningful behavioral traits beyond the schema. It does not explicitly state read-only status, but that is inherent in a search 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, each adding distinct value: purpose, output, and key capabilities/cost. It is front-loaded with the primary verb and resource, and contains no redundant filler.

  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 (14 params, no output schema, no annotations), the description provides essential context: return format, features, credit cost, and provider. It lacks explicit information about rate limits, error handling, or dependency on external API availability, but it is sufficient for a typical search 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% with detailed descriptions for all 14 parameters. The description adds minimal extra semantics, only referencing html=true and mobile results which are already in the schema. The credit cost mention is useful but not tied to parameter names.

  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 runs a Google search via Scrapingdog (/google), specifying the exact resource and action. It further enumerates the output types (organic results, ads, knowledge graph) and distinguishes it from sibling search engines like bing_search or duckduckgo_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 implies usage for Google-specific search needs by naming the search engine directly. It also highlights capabilities (localization, pagination, advanced filters, mobile) that inform when to use this tool. However, it lacks explicit exclusions or comparisons to alternatives, such as 'use bing_search for Bing results.'

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