brave
Server Details
Visit https://brave.com/search/api/ for a free API key. Search the web, local businesses, images,…
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- brave/brave-search-mcp-server
- GitHub Stars
- 1,249
- Server Listing
- Brave Search MCP Server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.1/5.
Each tool targets a distinct search modality (web, image, video, news, local, places) or processing step (summarizer, LLM context). Descriptions clearly differentiate purposes and chaining dependencies are explicitly noted.
All tool names follow a consistent `brave_<descriptive_suffix>` pattern using snake_case. The suffixes are specific to the operation (e.g., `image_search`, `llm_context`, `local_search`), making the purpose clear and predictably structured.
With 8 tools, the count is well-scoped for a search API covering multiple media types and AI enhancements. Each tool serves a distinct purpose without redundancy or unnecessary expansion.
The set covers all major search modalities and adds AI-oriented tools (summarizer, LLM context). Minor gaps exist (e.g., no direct location-to-POI search without a two-step flow), but the documented chaining addresses these adequately.
Available Tools
8 toolsbrave_image_searchImage searchARead-onlyInspect
Performs an image search using the Brave Search API. Helpful when you need pictures of people, places, things, graphic-design ideas, or art inspiration. Counts of up to 100 are supported.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query (max 400 characters and 50 words). | |
| count | No | Number of results (max 100; default 50). | |
| country | No | 2-letter country code (ISO 3166-1 alpha-2). Defaults to US. | |
| safesearch | No | Filter level for adult content. | |
| spellcheck | No | Whether to spellcheck the query. | |
| search_lang | No | 2-letter language code for the search. Defaults to en. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, etc. The description adds context about maximum count (100) but does not detail response format or other behavioral traits. For a read-only tool with annotations, this is adequate but not exceptional.
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?
Two sentences, no fluff, front-loaded with purpose. Every sentence serves a purpose.
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?
For a simple image search with good annotations and schema coverage, the description is sufficiently complete. It could mention output format (e.g., URLs, thumbnails) but is not necessary given the tool's simplicity.
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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema, though it mentions 'counts of up to 100' which aligns with the count parameter.
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 it performs an image search and gives examples of use cases. However, it does not explicitly differentiate from sibling tools like brave_video_search or brave_web_search, though the name implies image-specific functionality.
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 says 'Helpful when you need pictures...' which implies use cases but does not specify when not to use or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brave_llm_contextLLM context retrieval (RAG)ARead-onlyInspect
Retrieves pre-extracted, relevance-ranked web content using Brave's LLM Context API, optimized for AI agents, LLM grounding, and RAG pipelines. Unlike a traditional web search that returns links and short descriptions, this tool returns the actual substance of matching pages — text chunks, tables, code blocks, and structured data — so the model can reason over it directly. When relaying results in markdown-supporting environments, cite source URLs from the sources map.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Maximum number of search results considered to select the LLM context data. Default 20, max 50. | |
| query | Yes | The user's search query. Max 400 characters and 50 words. | |
| country | No | 2-letter country code (ISO 3166-1 alpha-2). Defaults to US. | |
| freshness | No | Filter results by recency. Use pd, pw, pm, py, or YYYY-MM-DDtoYYYY-MM-DD. | |
| spellcheck | No | Whether to spellcheck the query. | |
| search_lang | No | 2-letter language code for the search. Defaults to en. | |
| enable_local | No | Whether to enable local recall. | |
| context_threshold_mode | No | Mode used to determine the inclusion threshold for content. | |
| enable_source_metadata | No | Enable source metadata enrichment (site_name, favicon) in the sources attribute. | |
| maximum_number_of_urls | No | Maximum number of different URLs to include in LLM context. | |
| maximum_number_of_tokens | No | Approximate maximum number of tokens to include in context. Default 8192, max 32768. | |
| maximum_number_of_snippets | No | Maximum number of snippets (chunks of text) to include in LLM context. Default 50, max 256. | |
| maximum_number_of_tokens_per_url | No | Maximum number of tokens to include per URL. Default 4096, max 8192. | |
| maximum_number_of_snippets_per_url | No | Maximum number of snippets to include per URL. Default 50, max 100. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it returns text chunks, tables, code blocks, and a sources map, providing useful behavioral context beyond 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?
Three concise sentences, front-loaded with core functionality, each sentence adds distinct value (purpose, differentiation, usage guidance). No waste.
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 high schema coverage and read-only annotations, the description adequately covers tool behavior. Could mention response structure more, but sufficient for a RAG tool.
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%, so parameter semantics are well-documented in schema. Description does not add extra parameter-specific meaning beyond schema, earning baseline 3.
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 it retrieves pre-extracted, relevance-ranked web content using Brave's LLM Context API, optimized for AI agents and RAG, distinguishing it from traditional web search by returning actual content chunks.
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?
Explicitly contrasts with traditional web search, indicating when to use this tool over siblings like brave_web_search. Provides citation guidance but lacks explicit when-not usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brave_local_searchLocal POI search (enrichment)ARead-onlyInspect
Brave Local Search API returns enriched information (address, phone, hours, rating) for location-search results. Access requires the Brave Search API Pro plan; currently US-only. Two-step flow: first call brave_web_search with result_filter=locations to obtain locations.results[].id, then pass them here. NOTE: This tool takes location IDs from a prior web-search response; if you have a free-text query, call brave_web_search first.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | One or more location IDs returned by a prior `brave_web_search` with `result_filter=locations`. Up to 20 IDs per call. | |
| units | No | Measurement system. | |
| ui_lang | No | User interface language for the response, in the form <lang>-<country> (e.g. en-US). | |
| search_lang | No | 2-letter language code for the search. Defaults to en. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, non-destructive. Description adds context: requires Pro plan, US-only, two-step flow. No contradictions. Could mention rate limits or ID expiration, but sufficient.
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?
Single paragraph, no wasted words. Front-loaded with core purpose, then prerequisites and usage notes. Efficient and scannable.
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?
Covers main points: enrichment, prerequisites, US-only, Pro plan. No output schema, but mentions returned fields (address, phone, hours, rating). Could include idempotency or id lifespan, but adequate for typical use.
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 coverage is 100%, so baseline 3. Description adds meaning for 'ids' parameter: source from prior search and limit of 20 IDs. Other parameters have schema descriptions, but no extra from description.
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 uses specific verbs ('returns enriched information') and resource ('location-search results'), clearly distinguishing from siblings like brave_web_search by explaining the two-step flow.
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?
Explicitly states when to use (after brave_web_search with result_filter=locations) and when not (free-text queries should go to brave_web_search). Provides clear alternative with brave_web_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brave_news_searchNews searchARead-onlyInspect
Searches for news articles using Brave's News Search API. Use it when you need current news, breaking updates, or articles about specific topics.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query (max 400 characters and 50 words). | |
| count | No | Number of results to return (max 20; default 20). | |
| offset | No | Pagination offset (max 9, in units of `count`). | |
| country | No | 2-letter country code (ISO 3166-1 alpha-2). Defaults to US. | |
| ui_lang | No | User interface language for the response, in the form <lang>-<country> (e.g. en-US). | |
| freshness | No | Filter results by recency. Use pd (past day), pw (past week), pm (past month), py (past year), or a YYYY-MM-DDtoYYYY-MM-DD range. | |
| safesearch | No | Filter level for adult content. | |
| spellcheck | No | Whether to spellcheck the query. | |
| search_lang | No | 2-letter language code for the search. Defaults to en. | |
| text_decorations | No | Whether to include decoration markers (e.g. highlighting) in result strings. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=false, destructiveHint=false, and openWorldHint=true. The description adds no behavioral details beyond stating it uses Brave's News Search API (which is a source, not behavior). It does not mention rate limits, result structure, or account requirements. With annotations providing the safety profile, the description adds minimal extra value.
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 consists of two sentences: the first states the main function, the second provides usage guidance. Every word is purposeful, no fluff. It is well-structured and front-loaded.
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?
The tool has no output schema, and the description does not explain the return format (e.g., list of articles with title, source, date). It also does not mention pagination mechanics beyond the 'count' and 'offset' parameters. Given the tool has multiple parameters and is a search tool, the description could be more complete about what the agent can expect as output.
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%, meaning all 10 parameters are described in the schema. The tool description does not add any additional parameter semantics or contextual hints beyond what the schema already provides. Baseline of 3 is appropriate.
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 verb 'searches' and the resource 'news articles using Brave's News Search API'. It also provides usage context ('when you need current news, breaking updates, or articles about specific topics'), which differentiates it from sibling tools like brave_web_search or 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use the tool ('when you need current news, breaking updates, or articles about specific topics'). It does not specify when not to use it or name alternatives, but the context implies that for general web or image searches, other brother tools should be used. This is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brave_place_searchPlace search (POIs, cities, addresses, streets)ARead-onlyInspect
Searches Brave's Place Search API. A single call may populate any combination of results (POIs), cities, addresses, streets, and location (the resolved search area), depending on the query shape. Use for POIs near coordinates or a named area, browsing general POIs (omit query, supply coords or location), disambiguating bare city names, resolving specific addresses, or looking up streets. Anchor via latitude+longitude or location; with neither, query is required.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (max 50, default 20). | |
| query | No | Query string. Shape influences the response: POI-like queries return `results`; ambiguous city names return `cities`; address-/street-shaped queries with a geographic anchor return `addresses` and/or `streets`. Omit to browse general POIs in the supplied area. Required if neither `latitude`+`longitude` nor `location` is provided. | |
| units | No | Units of measurement for distance values. | |
| geoloc | No | Optional geolocation token used to refine results. | |
| radius | No | Bias toward results closer to the supplied coordinates, in meters. NOT a hard cutoff. | |
| country | No | 2-letter country code (ISO 3166-1 alpha-2). Defaults to US. | |
| ui_lang | No | User interface language for the response, in the form <lang>-<country> (e.g. en-US). | |
| latitude | No | Latitude of the geographical coordinates to search around (-90 to 90). Typically paired with `longitude`. | |
| location | No | Location string used as an alternative to lat/long. US: '<city> <state> <country>' (e.g. 'san francisco ca united states'). Non-US: '<city> <country>' (e.g. 'tokyo japan'). Capitalization and commas don't matter. | |
| longitude | No | Longitude of the geographical coordinates to search around (-180 to 180). Typically paired with `latitude`. | |
| safesearch | No | Filter level for adult content. | |
| spellcheck | No | Whether to spellcheck the query. | |
| search_lang | No | 2-letter language code for the search. Defaults to en. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, open-world behavior. The description adds that the response shape varies by query, which complements annotations 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with no redundancy. Each sentence adds meaningful information, front-loading the tool's purpose and key usage patterns.
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 tool's complexity (13 parameters, no output schema), the description covers the essential interplay between parameters and response types. It could briefly mention ordering or pagination, but is largely sufficient.
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?
All parameters have schema descriptions (100% coverage). The description adds value by explaining the role of 'query' in shaping the response and providing format examples for 'location', going beyond the raw schema.
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 it searches Brave's Place Search API for POIs, cities, addresses, streets, and locations. It lists specific response components and use cases, distinguishing it from sibling tools that handle images, news, videos, etc.
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?
It explains when to use the tool for various geospatial queries (POIs, addresses, city disambiguation) and how to anchor searches via coordinates or location. While it doesn't explicitly exclude other tools, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brave_summarizerAI-generated summaryARead-onlyInspect
Retrieves AI-generated summaries of web search results. Two-step flow: first call brave_web_search with summary=true to obtain summarizer.key, then pass it here. Pro AI tier required.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Summarizer key returned by a prior `brave_web_search` with `summary=true`. | |
| entity_info | No | Whether to include extra entity-info fields with citation metadata. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false; description adds operational context (two-step flow, tier requirement) without contradicting 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?
Three sentences, front-loaded with purpose, each sentence adds value with no 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?
No output schema exists; description lacks details about the summary output format. However, parameters are fully covered and operational flow is clear.
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 coverage is 100%, so baseline is 3. Description mentions 'key' in context but adds no new semantic meaning beyond what the schema provides for either parameter.
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 'Retrieves AI-generated summaries of web search results' and distinguishes from sibling tools by explaining the two-step flow involving brave_web_search.
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?
Explicitly describes the two-step flow and prerequisite ('first call brave_web_search with summary=true'), and states 'Pro AI tier required', providing 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_video_searchVideo searchBRead-onlyInspect
Searches for videos using Brave's Video Search API. Returns structured video results with metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query (max 400 characters and 50 words). | |
| count | No | Number of results to return (max 20; default 20). | |
| offset | No | Pagination offset (max 9, in units of `count`). | |
| country | No | 2-letter country code (ISO 3166-1 alpha-2). Defaults to US. | |
| ui_lang | No | User interface language for the response, in the form <lang>-<country> (e.g. en-US). | |
| freshness | No | Filter results by recency. Use pd (past day), pw (past week), pm (past month), py (past year), or a YYYY-MM-DDtoYYYY-MM-DD range. | |
| safesearch | No | Filter level for adult content. | |
| spellcheck | No | Whether to spellcheck the query. | |
| search_lang | No | 2-letter language code for the search. Defaults to en. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which describe the tool's safety and variability. The description adds 'Returns structured video results with metadata' but does not expand on behavior beyond annotations. No contradictions.
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?
A single, efficient sentence conveys the tool's purpose without fluff. Front-loading is adequate. Could be slightly more structured (e.g., bullet points for parameters), but it is not overly verbose.
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?
Despite full schema coverage for parameters, the description omits critical context such as pagination behavior, result structure details, or any constraints. For a search tool with 9 parameters, more completeness is expected to guide effective use.
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 coverage is 100% with parameter descriptions, so the description does not need to add further meaning. It does not elaborate on parameter usage or relationships, but the baseline is appropriate given full 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 clearly states it searches for videos via Brave's Video Search API. The name and title reinforce this. However, it does not explicitly differentiate from sibling search tools like 'brave_web_search' or 'brave_image_search', which would strengthen clarity.
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 provides no guidance on when to use this tool versus alternatives (e.g., 'brave_web_search' for general web content, 'brave_image_search' for images). No context on prerequisites, limitations, or scenarios is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brave_web_searchWeb searchARead-onlyInspect
Performs web searches using the Brave Search API and returns comprehensive search results with rich metadata. To chain into local-POI enrichment, pass result_filter=locations and feed the resulting locations.results[].id values into brave_local_search. To chain into the AI summarizer, pass summary=true and feed the returned summarizer.key into brave_summarizer.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query (max 400 characters and 50 words). | |
| count | No | Number of results to return (max 20; default 20). | |
| units | No | Measurement system used in result content. | |
| offset | No | Pagination offset (max 9, in units of `count`). | |
| country | No | 2-letter country code (ISO 3166-1 alpha-2). Defaults to US. | |
| summary | No | Set to true to request a summarizer key in the response. Pair with `brave_summarizer` to fetch the AI-generated summary text. Pro AI tier required. | |
| ui_lang | No | User interface language for the response, in the form <lang>-<country> (e.g. en-US). | |
| freshness | No | Filter results by recency. Use pd (past day), pw (past week), pm (past month), py (past year), or a YYYY-MM-DDtoYYYY-MM-DD range. | |
| goggles_id | No | Goggles ID for re-ranked results. See https://search.brave.com/help/goggles. | |
| safesearch | No | Filter level for adult content. | |
| spellcheck | No | Whether to spellcheck the query. | |
| search_lang | No | 2-letter language code for the search. Defaults to en. | |
| result_filter | No | Comma-separated list of result types to include. Available values: discussions, faq, infobox, news, query, summarizer, videos, web, locations. Use `locations` to chain into `brave_local_pois`. | |
| extra_snippets | No | Return up to 5 extra alternate snippets per result. Premium plans only. | |
| text_decorations | No | Whether to include decoration markers (e.g. highlighting) in result strings. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the tool is known to be safe. The description adds behavioral context about returning 'comprehensive search results with rich metadata' and explains chaining behavior. It doesn't contradict annotations and provides useful extra context beyond the schema.
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 extremely concise at three sentences, with no wasted words. It front-loads the main purpose and then provides chaining instructions, making it easy to parse quickly. 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?
For a tool with 15 parameters and no output schema, the description is fairly complete. It covers the core purpose and chaining use cases, but could briefly mention the response structure (e.g., web results, locations, summarizer fields). However, the chaining hints partially compensate for the missing output schema.
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%, so parameters are fully documented in the schema. The description adds value by explaining how to use `result_filter` and `summary` parameters for chaining, which goes beyond the schema descriptions. It enhances the semantic meaning of these key parameters.
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 it performs web searches using the Brave Search API, which is a specific verb and resource. It also differentiates from sibling tools by mentioning chaining capabilities, making the purpose unambiguous.
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 provides explicit guidance on when to use the tool (general web searches) and gives two specific chaining scenarios with exact parameter usage. It tells the agent how to chain into local-POI enrichment or the AI summarizer, which effectively distinguishes usage from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.