Server Quality Checklist

Tool Scores

• searxng_instance_infoA
  4/5.0
  Behavior4/5

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

  The description adds context beyond the readOnlyHint annotation by noting it fetches from 'all reachable configured instances' and describes the data categories returned. It does not mention caching behavior despite the refresh parameter, but the core behavioral traits (read-only, network-dependent) are covered.

  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 sentence that front-loads the action ('Discovers capabilities') and uses a compact, informative list for data categories. Every phrase contributes meaning without 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?

  For a read-only tool with no output schema, the description adequately covers its purpose and the data content it returns. It lacks explicit treatment of caching (hinted at by the refresh parameter) and behavior when instances are unreachable, which would be useful but are not critical for basic 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 coverage is 100% with clear parameter descriptions, so the tool description does not need to explain parameters. The description's list of output categories (e.g., categories.common/available) loosely relates to the 'category' filter but does not explicitly connect them, adding only marginal semantic value.

  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 the specific verb 'discovers' and names the resource: capabilities of SearXNG instances. It enumerates the exact content categories (categories, engines, defaults, locales, plugins), making it distinct from sibling tools like searxng_web_search and searxng_search_suggestions.

  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 when you need to inspect instance capabilities, but it does not explicitly state when to choose this over sibling search tools or provide exclusions. The context is inferred rather than stated.

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

• searxng_web_searchA
  4.2/5.0
  Behavior4/5

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

  Beyond annotations (readOnlyHint, openWorldHint), the description adds that it 'Calls an external SearXNG instance; availability depends on the SEARXNG_URL configuration.' This discloses a meaningful operational constraint not present in the annotations. It also warns about the exact parameter name, which is useful.

  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?

  Four short sentences, each with a distinct purpose: function, critical parameter note, usage tips, and follow-up action. No fluff, and the most important information (what it does and the critical parameter) is front-loaded.

  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 no output schema, the description reasonably explains the return format ('title, URL, and content snippet'), external dependency, pagination, narrowing options, and follow-up to web_url_read. It does not cover error handling or rate limits, but with read-only/open-world annotations and a well-covered schema, this is adequate.

  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 emphasizes the required `query` parameter and hints at combining `time_range` and `language`, but most parameter details are already in the schema. It adds minimal extra meaning beyond what the schema already 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 starts with a specific verb+resource: 'Searches the web using SearXNG and returns a list of results...' It clearly differentiates from siblings by explicitly directing follow-up to web_url_read for full text, and the search-vs-suggestions distinction is obvious from the tool names.

  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?

  Provides concrete usage guidance: 'Use pageno to paginate results; combine time_range and language to narrow scope' and 'follow up with web_url_read' for full-text reading. It does not explicitly compare with the sibling searxng_search_suggestions, but the main use case and a clear alternative (web_url_read) are covered.

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

• searxng_search_suggestionsA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and determinism profile. The description adds that results come from the configured instance, implying external dependency, but doesn't disclose rate limits or response format. With annotations doing the heavy lifting, 3 is appropriate.

  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 purpose and immediately followed by usage guidance. No filler or repetition of schema content.

  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 read-only suggestion tool with two well-documented parameters and no output schema, the description fully conveys purpose and usage. Annotations cover behavioral constraints, making this 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 coverage is 100%, with descriptions for both query and language including default values. The description's 'autocomplete suggestions' adds context but does not materially enhance what the schema already provides, so 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 'Returns autocomplete suggestions from the configured SearXNG instance' – a specific verb, resource, and source. The name and description distinguish it from sibling tools like web_search and instance_info.

  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?

  Explicitly says 'Use this to refine vague or partial queries before searching', providing clear when-to-use context and implying it is a precursor to web search. This is unambiguous guidance.

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

• web_url_readA
  4.8/5.0
  Behavior5/5

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

  Annotations provide readOnlyHint and openWorldHint, but the description adds extensive behavioral detail: content-type conversion rules, PDF extraction limits, binary rejection, FlareSolverr/Byparr fallback logic, modes, and error return behavior. This far exceeds what annotations alone communicate, with no contradictions.

  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 long but each sentence contributes necessary detail. It is front-loaded with the primary purpose and then branches into content types, limitations, modes, and usage. The solver fallback details are somewhat verbose and could be trimmed without losing core guidance, preventing a perfect score.

  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?

  With no output schema, the description adequately explains return format (markdown, fenced text, error string) and covers all major usage aspects: modes, pagination, unsupported types, and integration with the search tool. This makes it self-sufficient 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 covers all parameters 100%, so baseline is 3. The description adds value by explaining how parameters combine into three modes (full content with startChar/maxLength, section extraction, readHeadings) and notes mutual exclusivity. However, paragraphRange is not mentioned in the description, so it doesn't fully elaborate every parameter.

  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 first sentence clearly states 'Fetches a URL and returns readable content as markdown,' identifying the specific verb and resource. It distinctly differentiates from sibling tools (searxng_web_search, suggestions, instance info) which are search-oriented, not content retrieval.

  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?

  Explicitly states 'Use after searxng_web_search to read the full content of individual result URLs,' providing clear when-to-use guidance. Also lists exclusions (binary, media, OCR not supported) which inform 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.