Server Quality Checklist

Tool Scores

• brave_image_searchA
  3.7/5.0
  Behavior2/5

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

  Annotations only have openWorldHint=true, with no readOnlyHint or destructiveHint. The description does not disclose any behavioral traits such as side effects, authorization needs, or rate limits, leaving the agent without critical context.

  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?

  Three sentences: purpose, examples, and a markdown tip. Well-structured and front-loaded, though the markdown tip is slightly tangential.

  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 an output schema present and full parameter schema coverage, the description adds appropriate context about image results and markdown usage, though it could mention pagination briefly.

  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 provides 100% coverage with descriptions for all 6 parameters. The description adds no additional parameter meaning, so it meets the baseline of 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 it performs image searches using Brave API and provides specific use cases (pictures of people, places, etc.), distinguishing 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?

  The description explicitly states when to use it ('when you need pictures') and gives concrete examples, though it doesn't mention when not to use or compare directly with 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
  3.8/5.0
  Behavior4/5

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

  Annotations only have openWorldHint, so description carries burden. It explains that results_filter empty triggers extra result types (FAQ, Discussions, News, Video) beyond the core web results. This adds useful behavioral context beyond what annotations provide.

  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?

  Description is concise: one sentence for purpose, bullet list for use cases, then return format and special behavior. Every sentence earns its place, no fluff. Front-loaded with the main action.

  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 15 parameters and no output schema, the description covers return format (JSON list with title, desc, URL) and a key behavioral nuance (empty results_filter). It could detail more about other result types, but overall is sufficient for a search tool.

  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%, so baseline is 3. Description adds that count only affects web results (already in schema) and behavior of results_filter when empty (not in schema). This minor addition justifies maintaining the baseline without penalty.

  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 states it performs web searches and returns comprehensive results. It lists specific use cases but includes location-based queries, which are better served by a sibling tool (brave_local_search), potentially confusing the agent. Overall purpose is clear but slightly diluted by broad use cases.

  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 provides a 'When to use' list including general searches, local, news, videos, etc., but does not explicitly compare with sibling tools or state when not to use. It implies context but lacks exclusions or alternatives.

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

• brave_news_searchA
  3.9/5.0
  Behavior3/5

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

  Annotations include openWorldHint=true, indicating external data. The description discloses that results include title, url, description, and optional snippets. It does not cover rate limits, authentication, or error handling, but the core behavior is clear.

  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 structured into a purpose statement, 'When to use' list, return format, and examples. It is concise and front-loaded with the primary action.

  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 11 parameters and no output schema, the description adequately covers the return value (JSON list with title, url, description). It provides usage context but could detail pagination behavior or filtering nuances.

  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?

  Input schema has 100% parameter description coverage, so the baseline is 3. The description adds minimal value beyond the schema, but it does mention the query and result format in examples.

  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 news articles using Brave's News Search API. It specifies the verb 'searches' and resource 'news articles', and the title matches. This distinguishes it from siblings like brave_web_search and brave_image_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?

  The description includes a 'When to use' list with concrete scenarios like finding recent news, breaking updates, and researching current events. It lacks explicit when-not-to-use or alternatives, but the context of sibling names helps.

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

• brave_video_searchA
  4/5.0
  Behavior3/5

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

  The description implies a read-only search operation, which aligns with the openWorldHint annotation. However, it does not disclose any potential side effects, authentication needs, or error behaviors beyond what annotations provide. With no destructiveHint or readOnlyHint, a bit more context would be beneficial.

  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 only three sentences plus bullet points. It is front-loaded with purpose and usage, and every sentence adds unique value. No unnecessary repetition.

  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 9 parameters and no output schema, the description covers the return format (title, url, etc.) but omits details on pagination or result limitation. Overall it is reasonably complete for a search tool with well-documented schema.

  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. The description only mentions return fields, not adding meaning beyond what the schema provides. 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 clearly states the tool searches for videos using Brave's Video Search API, with a specific verb and resource. It distinguishes from sibling tools like brave_image_search and brave_web_search by focusing on video 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 provides clear contexts for video searches, such as discovering video content or finding specific creators. It does not explicitly state when not to use or name alternatives, but the context is clear enough for an AI agent.

  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.4/5.0
  Behavior4/5

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

  Discloses plan requirement and auto-fallback behavior. No annotations on safety/destructiveness, but description adds useful context without contradiction.

  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?

  Well-organized: first sentence summarizes, then bullet points for return info. No fluff; each sentence contributes meaning.

  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?

  No output schema, but description details return fields. Covers plan constraints, fallback, and use cases. Could mention more about parameter interactions but sufficient.

  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 covers all 15 parameters with descriptions; the tool description adds minimal parameter-specific value beyond listing return fields. Per rules, baseline 3 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 clearly states the tool searches for local businesses/places via Brave Local Search API, lists returned info (names, ratings, hours), and distinguishes from siblings by focusing on location queries.

  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 when to use (location queries, 'near me'), conditions (Pro plan only, else use brave_web_search), and mentions automatic fallback to web search.

  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?

  With minimal annotations (only title and openWorldHint), the description carries the full burden. It states the tool 'retrieves' summaries, indicating a read-only operation. It mentions optional features and prerequisites. However, it does not discuss error handling or rate limits, but overall behavior is clear.

  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 sentence, bullet-pointed 'When to use' section, and a final paragraph covering requirements. Every sentence adds value; there is no fluff or repetition. It is appropriately sized for the tool's complexity.

  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 three parameters and no output schema, the description covers purpose, prerequisites, optional features, and use cases adequately. It does not detail the output format beyond 'text summary', but that is sufficient for the tool's role as a summarizer.

  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 parameters are fully described in the schema. The description adds context beyond the schema: it explains that 'key' comes from a prior search result, and describes the optional booleans as enabling inline references and entity info. This adds meaningful guidance.

  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 retrieves AI-generated summaries via Brave's Summarizer API. It uses a specific verb ('retrieves') and resource ('summaries of web search results'), and distinguishes itself from sibling tools that perform other search types (image, local, news, video, web).

  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 lists when to use (e.g., 'when you need a concise overview') and provides requirements: must first call brave_web_search with summary=true and requires a Pro AI subscription. It also implies when not to use by contrasting with sibling tools.

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