Server Quality Checklist

Tool Scores

• brave_image_searchA
  3.9/5.0
  Behavior3/5

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

  With only openWorldHint in annotations, the description carries most of the behavioral burden. It does clarify the result is an image search and provides practical Markdown-formatting guidance, but it does not disclose any authentication, quota, network, or side-effect caveats. For a safe read-only search tool, this is adequate 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.

  Conciseness4/5

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

  The description is compact and front-loaded: the core purpose is in the first sentence, and the use-cases plus Markdown example are additive rather than redundant. The sentence has a slight looseness ('and more') but still 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 network image search tool with a detailed input schema and output schema, the description provides all the main common use cases and a helpful Markdown display tip. It lacks only an explicit routing to sibling search tools, but the schema and output schema already cover the technical details an agent needs.

  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 schema description coverage is 100% and all six parameters already have thorough descriptions, defaults, and bounds. The tool description adds no extra parameter-level meaning, so it remains at the baseline score of 3 for parameter 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 immediately states a specific verb+resource: 'Performs an image search using the Brave Search API.' The use cases (people, places, design ideas) make its scope unmistakable and distinguish it from the sibling web, video, news, and local search tools 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?

  It offers concrete guidance on when to use the tool: when pictures of people, places, things, art inspiration, or design ideas are requested. However, it does not explicitly tell the agent when not to use it or steer it toward a sibling alternative, so it falls one short of a full 5.

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

• brave_video_searchA
  3.9/5.0
  Behavior3/5

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

  The annotations provide only openWorldHint=true, which is minimal. The description mentions it 'returns structured video results with metadata' and lists the return fields, but doesn't disclose potential behaviors like pagination limits (offset max 9 is in schema, not description), rate limits, or any error conditions. For a read-only search tool, the safety profile is implied but not explicitly stated. This is adequate but could be richer.

  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 efficient: a one-sentence function summary, a 'When to use' bullet list, and a one-line return format summary. It is front-loaded with the core purpose and key use cases. Each bullet adds value without redundancy. Slightly more than necessary but well-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?

  The tool has 9 parameters but only 1 required (query). The schema provides exhaustive descriptions for every parameter, and the description covers the purpose and return format. Since there is no output schema, the description's note about 'JSON list of video-related results with title, url, description, duration, and thumbnail_url' compensates for missing output schema. Combined complexity is high, but the description plus schema cover everything an agent needs to call it correctly. Missing: explicit statement that it's read-only, but openWorldHint=true implies it's a safe world state. Overall 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 all 9 parameters are already documented in the schema. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is correct since the schema does the heavy lifting; no extra value from the description.

  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 ('Searches for videos'), the resource ('Brave's Video Search API'), and clearly differentiates from siblings by mentioning video-specific output fields (title, url, duration, thumbnail_url). It is immediately clear this is distinct from web, image, news, and local search 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?

  The description includes a 'When to use' section that lists concrete conditions: 'need to find videos related to a specific topic... discovering video content, getting video metadata, or finding videos from specific creators/publishers'. It doesn't explicitly state when NOT to use it or name alternatives, but the context is clear and sufficient for an agent to select it appropriately among siblings.

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

• brave_web_searchA
  4/5.0
  Behavior2/5

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

  The description does not disclose any behavioral traits beyond the action of performing a search. It does not mention whether the operation is read-only, any rate limits, authentication requirements, or side effects, which is a significant gap given the lack of readOnlyHint or destructiveHint 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 concise, with a clear opening statement, a bulleted list of use cases, and a note about results_filter. The structure is well-organized and easy to scan without unnecessary verbosity.

  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 gives a high-level overview of the return value ('comprehensive search results with rich metadata') and includes usage scenarios. While it does not detail the output structure (no output schema exists), it provides enough context to understand the tool's function and key behaviors.

  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 schema provides thorough descriptions for all parameters (100% coverage), and the description adds extra context, such as the behavior of result_filter when empty and how it affects returned result types. This goes beyond the schema's generic description.

  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: performing web searches via the Brave Search API and returning comprehensive results. It distinguishes itself from sibling search tools by explicitly mentioning 'web searches' and the general nature of the results.

  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 'When to use' section lists several concrete scenarios, such as general web searches, location-based queries, and news searches. However, it does not explicitly contrast with sibling tools (e.g., when to use local search instead), leaving some ambiguity about edge cases.

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

• brave_llm_contextA
  4.1/5.0
  Behavior4/5

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

  Annotations only include openWorldHint, so the description carries the burden of explaining behavior. It discloses that this is a retrieval operation returning actual page substance, relevance-ranked content, and a 'sources' map for citation. It does not mention auth, rate limits, or network side effects, but 'Retrieves ... using API' plus the content-type detail is meaningful beyond the annotation.

  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, a 'When to use' list, and a citation note. Some bullets overlap (RAG grounding, agent content, research material), but the overall length is justified for a tool with many use cases.

  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 rich input schema and output schema, the description is largely complete: it states what the tool returns, when to use it, and how to cite sources. It could be more explicit about when to prefer brave_web_search, but nothing essential for selecting or invoking the tool is missing.

  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 26 parameters. The description adds no parameter-level semantics beyond referencing the 'sources' map in the output, so the baseline 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?

  States a specific action ('Retrieves pre-extracted, relevance-ranked web content') and names the API. It explicitly contrasts with traditional web search by emphasizing content substance over links/descriptions, which differentiates it from sibling search 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?

  Provides a dedicated 'When to use' bullet list covering RAG, agent grounding, QA, and research. It implies the alternative (traditional web search) by saying results are needed when you want page contents, not just titles/URLs, but it does not name a sibling tool or give an explicit when-not-to-use section.

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

• brave_news_searchA
  4.2/5.0
  Behavior4/5

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

  With no readOnly or destructive annotations, the description carries the behavioral burden. It explicitly states the return format ('JSON list of news-related results with title, url, and description') and notes that some results may contain snippets. It also adds citation instructions for markdown environments. It does not cover error handling or rate limits, but the read-only nature of a search is implicit.

  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, starting with the core purpose and followed by usage contexts, return format, and examples. The three citation examples are somewhat repetitive but reinforce a key behavior. Overall, it is appropriately sized with minimal waste.

  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?

  Though the tool has 11 parameters, the schema fully documents them, and the description fills the gap left by the missing output schema by describing the JSON response and citation expectations. For a search tool with no side effects and clear sibling differentiation, the definition covers everything an agent needs to invoke it correctly.

  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?

  All parameters have descriptions in the input schema, giving 100% schema description coverage. The tool description does not add parameter-specific details beyond the schema, so the 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 opens with a specific verb and resource: 'searches for news articles using Brave's News Search API.' It clearly distinguishes this from sibling tools like brave_web_search by emphasizing news-specific use cases such as breaking news and current events. The scope is unambiguous and immediately actionable.

  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 'When to use' section lists concrete scenarios: finding recent news articles, getting breaking updates, researching current events, and gathering sources. However, it does not explicitly state when not to use this tool or name alternative sibling tools, so it provides clear context without exclusions.

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

• brave_local_searchA
  4.5/5.0
  Behavior4/5

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

  Annotations are limited (no hints visible in the prompt), but the description discloses key behaviors: it automatically falls back to brave_web_search if no local results are found, it returns business names/addresses/ratings/hours (though this is result content), and it notes the Pro plan requirement. This goes beyond what annotations would provide, though the description does not mention whether it makes network calls or any rate limits. Given no annotations, this is strong.

  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 moderately concise, with useful details packed in. The key use case and fallback are front-loadedaving some redundancy (e.g., 'location search results' near the start). It is structured well with bullets for return info. Slight verbosity but efficient.

  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 10 parameters in the schema with descriptions, the description adds context about return types (business names, addresses, ratings, hours) and fallback behavior sematically. It does not mention output format, but the schema covers parameter constraints. It also explains the plan requirement. Overall complete for an API tool description.

  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 schema is rich with descriptions for every parameter (count, units, country, etc.), so coverage is high. The description adds usage context (e.g., 'Use this when...') and the fallback behavior, which is not in the schema. It also explains the output fields (business names, addresses, ratings, phone, hours) that are not in the schema. Slight deduction because it doesn't clarify how parameters like 'summary' or 'freshness' apply specifically to local results, but overall adds 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 it searches for local businesses and places using Brave's Local Search API (spelled out in the opening). It distinguishes itself from brave_web_search by stating it is for physical locations, businesses, restaurants, services, and specifies it falls back to brave_web_search. The verb 'search' and resource 'local businesses and places' is specific.

  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?

  Provides explicit when-to-use guidance: 'when the query implies physical locations, businesses, restaurants, services, etc.' Also gives example triggers ('in my area', specific locations). It notes access restriction (Pro plan only) and tells the agent to check the user's plan, with a fallback to brave_web_search. This is excellent usage guidance.

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

• brave_summarizerA
  4.6/5.0
  Behavior4/5

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

  Annotations only include openWorldHint=true, offering no read/destructive hints. The description carries the burden and does so well: it says 'Retrieves' and 'Returns a text summary,' clearly implying a non-mutating read operation. It also discloses the subscription requirement. While it doesn't discuss error handling or rate limits, for a read-only summarizer the key behavioral traits 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 well-structured with a clear opening statement, a bulleted 'When to use' section, return details, and requirements. Each section is concise and front-loaded with the core purpose. No redundant sentences; every part 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?

  With 3 parameters, no output schema, and only openWorldHint annotation, the description covers the return type ('text summary'), prerequisite workflow, and optional features. It does not explain potential errors or the exact format of the key beyond referencing the response model, but for a tool of this simplicity it is largely complete.

  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 linking the optional boolean parameters to their features ('inline references to source URLs' and 'additional entity information'). It also explains the source of the required 'key' by referencing the prior web search with summary=true, which is crucial for parameter usage. This goes beyond the schema's minimal description.

  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 ('Retrieves AI-generated summaries'), a clear resource (web search results via Brave's Summarizer API), and explicitly differentiates from sibling search tools by focusing on summarization rather than search. It is immediately obvious 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 Guidelines5/5

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

  The description provides an explicit 'When to use' list with concrete scenarios (overviews, fact-checking, synthesis). It also states a hard prerequisite: 'Must first perform a web search using brave_web_search with summary=true parameter,' which effectively tells the agent the required precondition and the sibling tool to use. This is clear usage guidance.

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

• brave_place_searchA
  5/5.0
  Behavior5/5

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

  The description discloses that a single call may populate any combination of fields based on query shape, that 'radius' is a bias rather than a hard limit, and that 'count' caps results. It also details 'location' format requirements. These behaviors extend well beyond the openWorldHint annotation.

  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-organized with clear headings and bullet points, leading with purpose before details. It is dense with information but not redundant; every sentence contributes to selection or invocation understanding.

  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?

  The description covers all key usage scenarios, parameter interdependencies, and edge cases (e.g., radius not hard-limiting, location format). Given the output schema and full schema coverage, it omits only what is already structured, making it complete for an agent to call correctly.

  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?

  Even with 100% schema coverage, the description adds significant meaning: it maps query shapes to response types, requires geographic anchors for address/street queries, clarifies 'location' formatting, and explains radius/count behavior. This goes far beyond the schema's individual parameter 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 it 'Searches Brave's Place Search API' and enumerates the response categories (results, cities, addresses, streets, location). The title and content unambiguously differentiate it from sibling search tools by focusing on places and geographic data.

  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?

  A dedicated 'When to use' section lists five distinct scenarios with concrete examples (POIs near coordinates, general browsing, city disambiguation, address resolution, street lookup). It also explains anchor requirements and query prerequisites, giving agents explicit decision criteria.

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