Server Quality Checklist

Tool Scores

• rag_search_googleB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits. It mentions 'ddgs' (likely a DuckDuckGo search library) but does not explain that it uses DuckDuckGo instead of Google directly, nor does it discuss rate limits, authentication, or potential blocking. The 'RAG-like similarity sort' is vague.

  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 concise sentences: the first declares the action and resource, the second adds the key differentiating feature. No unnecessary words, well front-loaded.

  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 description covers the tool's basic purpose and a key feature (similarity sort), but lacks details about the source (DuckDuckGo vs Google), failure modes, and how to choose between siblings. The presence of an output schema partially compensates for missing return value descriptions.

  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 coverage is 100% with clear parameter descriptions. The description adds value by introducing 'RAG-like similarity sort', which implicitly relates to the 'top_k' parameter and distinguishes this tool from plain search. This provides context beyond the schema.

  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 'Search on Google' with a specific verb and resource, and adds 'RAG-like similarity sort' which differentiates it from sibling tools like 'rag_search_ddgs' and 'deep_research_google'. However, the phrase 'using ddgs' could be more explicit about the underlying source.

  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 its siblings (e.g., deep_research_google, rag_search_ddgs). There is no mention of prerequisites, limitations, or alternative tools for different scenarios.

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

• deep_research_ddgsA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden for behavioral disclosure. It explains that results are aggregated, scored, and deduplicated, but does not mention read-only nature, rate limits, auth requirements, or the scoring algorithm. The description gives moderate insight but lacks important operational details.

  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 very concise: two sentences that front-load the core purpose and key behaviors. Every sentence adds value without any fluff or repetition. It 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?

  Given the complexity (4 parameters, output schema exists), the description covers the essential purpose and behaviors. It doesn't detail the output structure, but the presence of an output schema mitigates that need. It provides sufficient context for an agent to understand the tool's role and how it differs from siblings.

  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 parameters clearly. The tool description does not add any additional meaning beyond what the schema provides; it only restates the overall process. Baseline score of 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 the tool's purpose: 'Perform deep research across multiple search terms using ONLY DuckDuckGo.' It specifies the resource (DuckDuckGo) and the actions (aggregates, scores, removes duplicates). It distinguishes itself from sibling tools like deep_research_google by explicitly limiting to DuckDuckGo.

  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 lacks guidance on when to use this tool versus alternatives (e.g., deep_research, deep_research_google). It does not provide explicit when-to-use or when-not-to-use criteria, nor does it mention any prerequisites or contraindications.

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

• deep_research_googleA
  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 bears full responsibility for behavioral disclosure. It mentions aggregation, scoring by relevance, and duplicate removal, but does not address authentication, rate limits, error handling, or the format of returned content. More detail is needed for a research 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 core purpose, and no extraneous information. 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?

  Given the presence of an output schema (not shown but indicated), the description does not need to explain return values. It covers the aggregation and scoring logic. However, it could mention the type of content returned (e.g., snippets, URLs) to be 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?

  The input schema covers all parameters with descriptions (100% coverage). The tool description does not add meaning beyond the schema; it only explains the overall process. 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 the tool's function: 'Perform deep research across multiple search terms using ONLY Google.' It specifies the verb (perform deep research) and resource (Google), and distinguishes from siblings like deep_research_ddgs by emphasizing 'ONLY Google'.

  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 context by specifying 'using ONLY Google', but does not explicitly state when to use this tool versus siblings or when not to use it. The sibling names provide some context, but the description lacks direct guidance.

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

• rag_search_ddgsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behaviors: fetching results, scoring by similarity, returning top-k as markdown, and mentions increased processing time for more results.

  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 long, front-loaded with purpose, and contains no unnecessary 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 the tool's moderate complexity (search + scoring) and the presence of an output schema, the description adequately covers usage but could mention the output format (markdown) more explicitly.

  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. The description adds overall process context but does not enhance individual parameter 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 it searches the web using DuckDuckGo and returns results with RAG-like similarity scoring, distinguishing it from sibling tools like rag_search_google.

  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 when to use the tool (web search with semantic relevance), but does not explicitly state when not to use it or mention alternatives besides the sibling names.

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

• deep_researchA
  4.6/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 explains that the tool aggregates results, scores by relevance, and removes duplicates. It does not mention any destructive actions or side effects, but as a read-only research tool, this is sufficient. The output schema further clarifies return values.

  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 clear sections (main purpose, available backends, usage guidance). It is informative without being overly verbose. Some redundancy exists (backends listed twice), but overall efficient.

  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 the complexity of 5 parameters, 1 required, and the presence of an output schema and sibling tools, the description is thorough. It covers what the tool does, how to use it, backend selection guidance, and references to alternative tools. No gaps in essential information.

  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 coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of search_terms (multiple related queries), listing available backends, and providing usage recommendations for backends. This goes beyond the schema's descriptions.

  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 that the tool performs deep research across multiple search terms using specified backends, aggregates results, scores by relevance, and returns the most relevant content with duplicates removed. It distinguishes itself from sibling tools like deep_research_google and deep_research_ddgs by mentioning them as shortcuts.

  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 includes a dedicated 'USAGE GUIDANCE FOR LLM' section detailing when to use different backends, how to ask users for preferences, and specific recommendations for various use cases. It also mentions sibling tools as alternatives for single-backend scenarios.

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