brave

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

Annotations only provide openWorldHint. The description adds valuable behavioral context: it identifies the external API (Brave Search), and crucially provides specific guidance on output formatting (''), revealing the structure of returned results not evident in the input schema. Does not cover rate limits or error handling, but provides actionable usage guidance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three well-structured sentences with no waste. Front-loaded with the core action, followed by use cases, then a specific implementation tip for markdown rendering. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (per context signals), the description appropriately omits detailed return value explanations. It covers the tool's purpose, usage contexts, and provides a concrete code example for handling results. With 100% schema coverage and existing annotations, the description is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all 6 parameters (query, count, country, safesearch, spellcheck, search_lang) fully documented in the schema. The description does not add parameter-specific guidance, so baseline 3 is appropriate per scoring rules.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool 'Performs an image search using the Brave Search API' with specific verb and resource. It distinguishes from siblings (brave_web_search, brave_video_search, etc.) by specifying 'image search' and providing concrete use cases like 'pictures of people, places, things, graphic design ideas, art inspiration'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides clear positive guidance on when to use ('when you need pictures of people, places, things...'), helping the agent identify appropriate contexts. Lacks explicit 'when not to use' or named alternatives (e.g., 'use brave_web_search for text results'), but the use case examples effectively communicate the scope.

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

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

Annotations only provide openWorldHint. The description adds critical behavioral context: the Pro plan access restriction (auth requirement), automatic fallback to brave_web_search if no results found, and detailed return structure (business names, ratings, hours). Deducted one point as it doesn't mention rate limits or caching behavior, though these may not be critical for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Well-structured with clear sections: access requirements, core purpose, return values, and usage triggers. Front-loaded with critical Pro plan warning. Minor verbosity in opening sentence repeating 'Brave Local Search API' and 'enrichments,' but overall efficient for the complexity (15 parameters, fallback logic, auth requirements).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Strong completeness given no output schema exists. The description compensates by listing specific return fields (addresses, ratings, hours). Covers authentication, sibling differentiation, and fallback behavior. Deducted one point as it could briefly acknowledge the primary 'query' parameter or pagination behavior explicitly, though this is minor given schema completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, establishing a baseline of 3. The description implies the query parameter through usage examples but does not add semantic context, syntax guidance, or parameter relationships beyond what the schema already provides. No penalty since schema is comprehensive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool 'Searches for local businesses and places using Brave's Local Search API' with specific scope (physical locations, businesses, restaurants) and distinguishes from brave_web_search by noting the Pro plan requirement and local focus. It also details specific return values (ratings, hours, phone numbers) clarifying the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Excellent explicit guidance: states 'confirm the user's plan before using this tool (if the user does not have a Pro plan, use the brave_web_search tool)' providing a clear alternative, and specifies exact trigger phrases ('near me', 'in my area', 'in San Francisco') for when to select this over siblings.

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

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

Annotations only provide openWorldHint=true. The description adds valuable behavioral context: it discloses the return format (JSON list with title/url/description), mentions that snippets may be included, and provides specific citation formatting requirements for markdown output. Does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Well-structured with clear sections (Purpose → When to use → Returns → Citation guidance → Examples). Front-loaded with the core function. However, three full citation examples create verbosity; while helpful for format clarity, they could be condensed or the third example omitted without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description appropriately explains return values (JSON structure with title/url/description) and adds crucial citation requirements for news attribution. Given the complexity (11 params) and lack of output schema, it adequately covers behavioral context, though it could briefly mention pagination concepts (offset parameter exists in schema but conceptual explanation is absent).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage across all 11 parameters, the schema carries the full semantic load. The description references 'based on the user's query' implying the required query parameter, but adds no additional parameter guidance beyond what the comprehensive schema already provides. Baseline 3 is appropriate given high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it 'searches for news articles using Brave's News Search API'—specific verb, resource, and provider. It clearly differentiates from siblings (brave_web_search, brave_image_search, etc.) by focusing specifically on 'news articles' and 'current news information' rather than general web or media content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides explicit 'When to use' section with four specific scenarios (recent articles, breaking news, current events, news analysis). However, it lacks explicit guidance on when NOT to use this tool versus alternatives like brave_web_search, and doesn't mention prerequisites or rate limits.

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

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

Annotations only provide openWorldHint=true. The description adds significant behavioral context: the Pro AI subscription requirement (auth), the dependency chain on brave_web_search, and the output format ('text summary that consolidates information'). It mentions optional features (inline references, entity info) that explain behavioral variations. Lacks rate limits or error conditions, preventing a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Well-structured with clear sections (purpose, when to use, returns, requirements). Front-loaded with the core function. No redundant text—every sentence provides specific guidance on usage constraints, prerequisites, or output characteristics. Appropriate length for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema exists, the description appropriately explains return values ('text summary'). With 100% schema coverage and only 3 simple parameters, the description compensates by explaining the critical prerequisite workflow and subscription requirements. Complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage (baseline 3). The description adds value by explaining what the boolean parameters actually do in context: 'inline references to source URLs' maps to inline_references, and 'additional entity information' maps to entity_info. It implies the key's origin through the workflow description, though explicit parameter semantics for 'key' would strengthen this further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Retrieves') and clear resource ('AI-generated summaries of web search results using Brave's Summarizer API'). It effectively distinguishes from sibling tools by specifying this processes existing search results rather than performing raw searches like brave_web_search or media-specific searches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Contains an explicit 'When to use:' section with four specific scenarios. Crucially, it states the prerequisite workflow: 'Must first perform a web search using brave_web_search with summary=true parameter,' explicitly naming the sibling tool required for operation. Also notes the subscription requirement, preventing inappropriate invocations.

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

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

The description effectively supplements the openWorldHint annotation by confirming the use of 'Brave's Video Search API' and detailing the return format ('JSON list of video-related results with title, url, description, duration, and thumbnail_url') since no output schema is provided. It does not mention rate limits or authentication requirements, but aligns well with the external resource hint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured with three distinct sections: purpose statement, usage guidelines, and return value specification. It is appropriately sized with no redundant text—every sentence provides necessary context not duplicated in the schema or annotations. Information is front-loaded with the core purpose stated immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich input schema (9 parameters, 100% coverage) and lack of output schema, the description adequately compensates by describing the JSON return structure. It covers tool purpose, usage scenarios, and output format. Could be improved by mentioning pagination behavior or country/language filtering strategies, but is sufficiently complete for tool selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema comprehensively documents all 9 parameters including constraints and defaults. The description provides no additional parameter semantics, which is acceptable given the baseline of 3 for high schema coverage, though it could have highlighted important parameters like 'freshness' or pagination patterns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 and returns structured video results with metadata,' providing specific verb and resource. However, it does not explicitly distinguish from sibling tools like brave_web_search or brave_image_search, though the 'When to use' section implies video-specific use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Includes a dedicated 'When to use:' section with specific scenarios ('find videos related to a specific topic,' 'discovering video content'). This provides clear positive guidance for the agent. Lacks explicit 'when not to use' guidance or mention of alternatives (e.g., brave_web_search for general web pages), preventing a score of 5.

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

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

With only openWorldHint in annotations, the description carries significant weight. It adds valuable behavioral context: the return format (JSON list with title/description/URL) and the conditional behavior where empty results_filter may include FAQ/News/Video results. It does not contradict the openWorldHint annotation and appropriately discloses the comprehensive nature of the search.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is excellently structured with a one-sentence purpose summary, a bulleted 'When to use' list for scannability, and precise notes on return values and parameter behavior. Every sentence serves a distinct purpose without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity (15 parameters) and absence of an output schema, the description adequately covers the tool's purpose, usage contexts, and basic return structure. The 100% schema parameter coverage compensates for the lack of detailed output schema documentation, though additional detail on the structure of specialized result types (news, videos) would strengthen it further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While the schema has 100% coverage (baseline 3), the description adds specific semantic value by explaining the behavior of the 'results_filter' parameter when empty versus its default state, clarifying that an empty filter yields additional result types (FAQ, Discussions, etc.) beyond the default web+query results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Performs web searches using the Brave Search API,' identifying the specific verb, resource, and underlying service. It distinguishes itself from siblings (brave_news_search, brave_video_search, etc.) by positioning itself as the comprehensive, general-purpose search that can return diverse result types including web pages, FAQs, discussions, and videos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description includes an explicit 'When to use' section listing specific scenarios (general information, location-based queries, news, videos/FAQs). However, it does not explicitly name sibling alternatives (e.g., 'use brave_news_search for dedicated news filtering') or provide negative constraints (when not to use this tool).

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