Server Quality Checklist

Tool Scores

• get_suggestionsA
  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 of behavioral disclosure. It adequately describes the core functionality (autocomplete suggestions) but lacks details about rate limits, response format, error conditions, or performance characteristics. The description doesn't contradict any annotations since none exist.

  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 well-structured with a clear opening statement followed by a purpose explanation and specific usage guidelines. While slightly verbose in the bulleted list, every sentence adds value and the information is front-loaded appropriately for an AI agent.

  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 read-only tool with no annotations and no output schema, the description provides adequate context about what the tool does and when to use it. However, it lacks information about return values, error handling, and operational constraints that would be helpful given the absence of structured metadata.

  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 both parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'query prefix' and 'search suggestions' context, but doesn't provide additional syntax, format, or constraint details. This meets the baseline for high schema coverage.

  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 purpose with specific verbs ('Get search suggestions/autocomplete') and resource ('for a query prefix'), distinguishing it from siblings like 'search' by focusing on autocomplete rather than full search results. It explicitly mentions similarity to search engine autocomplete functionality.

  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?

  The description provides explicit usage scenarios in a bulleted list: getting autocomplete suggestions, discovering related terms, helping formulate queries, and exploring search variations. It clearly indicates when to use this tool versus alternatives like 'search' by focusing on partial queries and discovery.

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

• searchA
  4.2/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 of behavioral disclosure. It describes what the tool does ('performs web searches across multiple search engines aggregated by SearXNG') and what it returns ('comprehensive results including titles, URLs, content snippets, and metadata'), but lacks details on rate limits, authentication needs, error handling, or pagination behavior beyond the 'page' parameter. It adequately covers basic behavior but misses advanced operational 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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by a brief explanation of functionality, and ends with a bulleted list of use cases. Every sentence adds value without redundancy, and the information is front-loaded for quick comprehension.

  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 moderate complexity (7 parameters, no output schema, no annotations), the description is reasonably complete. It explains the tool's purpose, usage guidelines, and basic behavior, but lacks details on output format specifics, error conditions, or advanced behavioral traits like rate limiting. It compensates well for the absence of annotations and output schema, though not fully.

  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 all 7 parameters thoroughly. The description adds marginal value by mentioning filtering capabilities ('filter by categories, specific engines, language, and time range') and listing some category examples, but doesn't provide additional syntax, format details, or constraints beyond what the schema specifies. This meets the baseline for high schema coverage.

  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 purpose with specific verbs ('Search the web using SearXNG search engine') and resources ('across multiple search engines aggregated by SearXNG'). It distinguishes itself from sibling tools (get_config, get_suggestions, health_check) by focusing on web search functionality rather than configuration retrieval, suggestions, or system health checks.

  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?

  The description provides explicit guidance on when to use this tool through a bulleted list: 'Use this when you need to: - Search for information on the web - Find recent news or articles - Search for images or videos - Get diverse results from multiple search engines - Research a topic across different sources'. This clearly defines appropriate use cases without mentioning alternatives, which is sufficient given the tool's distinct purpose among siblings.

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

• health_checkA
  4.3/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 discloses that the tool checks health status and accessibility, implying a read-only, non-destructive operation useful for diagnostics. However, it lacks details on error handling, response format, or potential side effects like network timeouts, leaving some behavioral aspects unclear.

  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 well-structured and front-loaded with the core purpose, followed by usage guidelines in a bulleted list. It avoids unnecessary details, but the bulleted list could be slightly more concise (e.g., by combining related points), though overall it's efficient 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 simplicity (0 parameters, no output schema, no annotations), the description is reasonably complete. It explains the purpose, usage, and context effectively. However, without an output schema, it could benefit from briefly mentioning what the health check returns (e.g., status codes or messages), slightly limiting completeness for diagnostics.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the input. The description appropriately adds no parameter-specific information, as none are needed, maintaining clarity without redundancy. This meets the baseline for tools with no 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's purpose with specific verbs ('check', 'verifies') and resource ('SearXNG instance'), explicitly distinguishing it from sibling tools like 'search' by focusing on health verification rather than search operations. It directly answers what the tool does without being tautological.

  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?

  The description provides explicit usage scenarios in a bulleted list (e.g., 'Verify the SearXNG instance is accessible', 'Diagnose connection issues'), clearly indicating when to use this tool. It implicitly distinguishes from alternatives like 'search' by specifying it's for pre-search availability checks, though it doesn't explicitly name sibling tools.

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

• get_configA
  4.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 of behavioral disclosure. It clearly indicates this is a read-only operation ('retrieves') and specifies what data is returned, but lacks details on potential rate limits, authentication requirements, error conditions, or response format. The description adds useful context about the scope of configuration data but doesn't fully compensate for the absence of 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 well-structured and front-loaded with the core purpose in the first sentence. Each subsequent sentence and bullet point adds specific value without redundancy. The bullet points efficiently organize usage scenarios, making the description easy to scan while maintaining complete 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?

  For a zero-parameter read-only tool with no output schema, the description provides comprehensive information about what configuration data is retrieved and when to use it. However, it doesn't describe the response format or structure, which would be helpful given the absence of an output schema. The description covers the essential context but leaves some ambiguity about what the return data looks like.

  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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on explaining what configuration data will be retrieved, which adds value beyond the empty 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 specific action ('retrieves') and resource ('SearXNG instance configuration'), listing concrete components like search engines, categories, locales, plugins, and settings. It distinguishes from siblings like 'search' (which performs searches) and 'get_suggestions' (which provides query suggestions) by focusing on configuration discovery rather than search operations.

  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?

  The description explicitly provides four bullet points detailing when to use this tool: to discover available search engines, see enabled categories, check supported languages/locales, and understand instance capabilities. It implicitly distinguishes from 'search' (which is for executing searches) and 'get_suggestions' (for query autocompletion) by focusing on configuration discovery rather than search functionality.

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