Server Quality Checklist

Tool Scores

• image_searchA
  3.7/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 mentions 'No API key' and backend choices, but does not explicitly state that this is a read-only operation, whether results are scraped, how errors are surfaced, or if there are rate limits. The 'search' wording implies non-destructive behavior, but an agent gains little insight beyond a typical 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.

  Conciseness4/5

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

  The description is compact and well-structured: a one-line purpose statement followed by a tabulated args list. Every line serves a purpose, and the format is easy to scan. It earns its place given the empty schema descriptions, though a shorter phrasing could have been slightly tighter.

  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 read-only search tool with an output schema present, the description covers invocation essentials: purpose, all parameters with allowed values, authentication status (no API key), and backend selection. It omits only explicit sibling-routing guidance and behavioral caveats, which are minor because the output schema already addresses return values.

  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 0%, so the description compensates by documenting all five parameters: query, max_results with range constraint, region with examples, safesearch with allowed values, and backend with 'auto' plus specific engines. This adds meaningful value beyond the bare schema defaults, though it could further explain the region's effect and safesearch semantics.

  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 'Image search via DDGS (DuckDuckGo/Bing image backends)', which names the operation (search) and resource (images) and explicitly distinguishes it from siblings like news_search and video_search. The specific backends further differentiate it from web_search, leaving no ambiguity about what the tool does.

  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 states 'No API key' and lists backend options, implying this is the image-specific search tool among the siblings. However, it never explicitly says 'use this when you need images' or contrasts it with web_search, news_search, etc. The usage context is implied by the resource and sibling names rather than directly stated.

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

• video_searchA
  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 carries the full burden. It adds useful behavioral context by stating 'No API key' and identifying the DDGS/DuckDuckGo video backend, which tells the agent that no authentication setup is needed. However, it does not disclose rate limits, error behavior, or whether results are live vs cached. The read-only nature of search is reasonably inferred.

  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 compact and well-structured: a two-sentence overview followed by a clean Args list. Every line adds value, and the key constraint ('No API key') is front-loaded. There is no filler or repetition of schema defaults.

  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 five-parameter search tool with an output schema and zero schema-level descriptions, the description covers all invocation essentials: parameter meanings, ranges, allowed values, and auth-free access. It does not discuss rate limits or when to prefer sibling tools, but the core instructions for correct invocation are complete.

  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?

  Schema description coverage is 0%, and the description fully compensates by explaining all five parameters. It includes critical constraints and examples: max_results range (1-25), region formats ('us-en', 'wt-wt'), backend choices ('auto' or 'duckduckgo'), and snippet_chars semantics (max description length, 0 = none). This is far more informative than the bare schema titles and defaults.

  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 starts with 'Video search via DDGS (DuckDuckGo video backend)', a specific verb and resource that clearly identifies the tool as a video-focused search utility. This distinguishes it from siblings like image_search, web_search, and news_search without needing to inspect their schemas.

  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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, such as 'use web_search for general web queries' or 'use image_search for images'. The tool name and first line imply it is for videos, but the conditional context for choosing it over siblings is absent.

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

• news_searchA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries full disclosure responsibility. It usefully discloses auth requirements, backend options, result limits, and snippet truncation behavior, but it does not mention rate limits, error behavior, or what the returned news results contain. For a non-mutating search tool this is acceptable but not rich.

  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 compact two-line summary followed by a scannable Args list. Every line adds useful parameter or behavior information, with no filler and no repetition of schema-default information.

  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 six parameters, no annotations, and an output schema, the description covers the caller-facing details needed to invoke the tool correctly: all parameters, constraints, and the no-key requirement. It is nearly complete, though edge behavior such as rate limits and empty-result handling is left undocumented.

  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?

  The input schema provides only types and defaults, so the description must add the meaning of all six parameters. It does so for every parameter, including allowed ranges, region examples, timelimit values, backend choices, and the meaning of snippet_chars=0.

  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?

  States that the tool performs news search via DDGS with DuckDuckGo/Bing/Yahoo news backends and no API key. This clearly distinguishes it from image_search, video_search, and web_search siblings.

  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 tool is positioned as a news-specific search, which implies it should be selected over web/image/video search, but it never explicitly states when to prefer it or when to choose a sibling. Usage guidance is inferred from the news focus rather than stated.

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

• web_searchA
  4.4/5.0
  Behavior3/5

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

  The description reveals useful behavioral facts, such as no API key required and use of DDGS metasearch, which are not in annotations. However, with no annotations provided., it does not disclose potential limitations like rate limits or network dependency, leaving some behavioral burden uncovered.

  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 front-loaded with the core purpose and API requirement, then uses a clean Args block for parameters. Every line carries useful information and none is redundant with the schema beyond necessary clarification.

  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 seven parameters and zero schema descriptions, this descrption covers all of them with concrete options and examples. It also notes key operational context such as no API key and backend choice. With an output schema present, return values need not be described here.

  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?

  Schema description coverage is 0%, and this descripiton fully compensates. For every parameter it gives allowed values, formats, examples, defaults, or recommendationex: region examples, timelimit semantics, backend options, and max_results range. This is highly actionable for an agent.

  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 states a specific verb and resource: web search via DDGS metasearch. It explicitly says 'web results', which distinguishes it from sibling tools like image_search, news_search, and video_search without ambiguity.

  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 context: this is a web search tool, distinct from other search types. It does not explicitly name alternatives or list when-not-to-use conditions, but 'web results' plus the sibling tool names make the intended use case clear.

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

• search_statusA
  4.5/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 that the tool reports configuration details and performs a live ping search, which tells the agent that a live network operation is involved. It does not warn about possible latency or failure modes, but the behavior is adequately described for a diagnostic call.

  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?

  A single, front-loaded sentence packs all relevant information with a colon-structured list. Every segment adds a specific piece of diagnostic info; there is no filler or repetition.

  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 no-parameter status tool with an output schema, the description covers the purpose, the categories of information returned, and the diagnostic nature. The output schema can carry the detailed return structure, so nothing needed for correct invocation is missing.

  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 takes zero parameters, so the description does not need to explain parameter meaning. The empty schema makes parameter semantics a non-issue; the baseline for zero-parameter tools 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 uses a specific category 'Health/diagnostics' and enumerates the exact information returned: DDGS version, backend/region/timeout/proxy, available backends per category, and live ping. This distinguishes it clearly from the sibling search tools, which perform searches rather than report system status.

  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 'Health/diagnostics' prefix gives clear context for when to call this tool: checking configuration and connectivity, not performing a content search. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent should not confuse it with the search siblings.

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

• web_extractA
  4.6/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 behavioral disclosure burden. It reveals that output is markdown by default, that content is truncated via max_chars, and that fmt controls markdown/plain/rich/raw-HTML/bytes-to-str conversion. This gives a strong model of behavior without dependency on schema or annotations.

  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 compact and well-structured: a one-sentence purpose, a one-sentence usage context, then a terse Args list. Every line adds value, and the most critical facts (default format and usage order) are 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?

  An output schema exists, so return value details need no explanation. The description covers the operation, the param family with defaults, and the intended position in a search-then-extract workflow. Nothing an agent needs to call this tool correctly is missing.

  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?

  Schema description coverage is 0%, and the description compensates fully: it explains urls are 1-5 absolute http(s) URLs, max_chars caps returned content per page with default 600, and fmt enumerates all accepted values including their semantic differences. This is exactly the parameter clarification the schema lacks.

  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 and resource: 'Extract readable content from 1-5 web pages (markdown by default).' This clearly identifies the operation and scope, and the placement relative to search tools distinguishes it as a follow-up retrieval action rather than a 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?

  It explicitly says 'Use after web_search/news_search to read the actual page content,' giving the agent clear context for when this tool is appropriate. It does not spell out when not to use it, but the intended workflow is unambiguous.

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