Integrates the Brave Search API, providing comprehensive search capabilities including web search, local business search, place search, image search, video search, news search, LLM context, and AI-powered summarization.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@brave-search-mcp-server search for latest AI research papers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server implementation that integrates the Brave Search API, providing comprehensive search capabilities including web search, local business search, place search, image search, video search, news search, LLM context, and AI-powered summarization. This project supports both STDIO and HTTP transports, with STDIO as the default mode.
To follow established MCP conventions, the server now defaults to STDIO. If you would like to continue using HTTP, you will need to set the BRAVE_MCP_TRANSPORT environment variable to http, or provide the runtime argument --transport http when launching the server.
brave_image_searchVersion 1.x of the MCP server would return base64-encoded image data along with image URLs. This dramatically slowed down the response, as well as consumed unnecessarily context in the session. Version 2.x removes the base64-encoded data, and returns a response object that more closely reflects the original Brave Search API response. The updated output schema is defined in src/tools/images/schemas/output.ts.
Related MCP server: Brave Search MCP Server
brave_web_search)Performs comprehensive web searches with rich result types and advanced filtering options.
Parameters:
query (string, required): Search terms (max 400 chars, 50 words)
country (string, optional): Country code (default: "US")
search_lang (string, optional): Search language (default: "en")
ui_lang (string, optional): UI language (default: "en-US")
count (number, optional): Results per page (1-20, default: 10)
offset (number, optional): Pagination offset (max 9, default: 0)
safesearch (string, optional): Content filtering ("off", "moderate", "strict", default: "moderate")
freshness (string, optional): Time filter ("pd", "pw", "pm", "py", or date range)
text_decorations (boolean, optional): Include highlighting markers (default: true)
spellcheck (boolean, optional): Enable spell checking (default: true)
result_filter (array, optional): Filter result types (default: ["web", "query"])
goggles (array, optional): Custom re-ranking definitions
units (string, optional): Measurement units ("metric" or "imperial")
extra_snippets (boolean, optional): Get additional excerpts (Pro plans only)
summary (boolean, optional): Enable summary key generation for AI summarization
brave_local_search)Searches for local businesses and places with detailed information including ratings, hours, and AI-generated descriptions.
Parameters:
Same as brave_web_search with automatic location filtering
Automatically includes "web" and "locations" in result_filter
Note: Requires Pro plan for full local search capabilities. Falls back to web search otherwise.
brave_video_search)Searches for videos with comprehensive metadata and thumbnail information.
Parameters:
query (string, required): Search terms (max 400 chars, 50 words)
country (string, optional): Country code (default: "US")
search_lang (string, optional): Search language (default: "en")
ui_lang (string, optional): UI language (default: "en-US")
count (number, optional): Results per page (1-50, default: 20)
offset (number, optional): Pagination offset (max 9, default: 0)
spellcheck (boolean, optional): Enable spell checking (default: true)
safesearch (string, optional): Content filtering ("off", "moderate", "strict", default: "moderate")
freshness (string, optional): Time filter ("pd", "pw", "pm", "py", or date range)
brave_image_search)Searches for images with metadata including URLs, dimensions, and confidence scores.
Parameters:
query (string, required): Search terms (max 400 chars, 50 words)
country (string, optional): Country code (default: "US")
search_lang (string, optional): Search language (default: "en")
count (number, optional): Results per page (1-200, default: 50)
safesearch (string, optional): Content filtering ("off", "strict", default: "strict")
spellcheck (boolean, optional): Enable spell checking (default: true)
brave_news_search)Searches for current news articles with freshness controls and breaking news indicators.
Parameters:
query (string, required): Search terms (max 400 chars, 50 words)
country (string, optional): Country code (default: "US")
search_lang (string, optional): Search language (default: "en")
ui_lang (string, optional): UI language (default: "en-US")
count (number, optional): Results per page (1-50, default: 20)
offset (number, optional): Pagination offset (max 9, default: 0)
spellcheck (boolean, optional): Enable spell checking (default: true)
safesearch (string, optional): Content filtering ("off", "moderate", "strict", default: "moderate")
freshness (string, optional): Time filter (default: "pd" for last 24 hours)
extra_snippets (boolean, optional): Get additional excerpts (Pro plans only)
goggles (array, optional): Custom re-ranking definitions
brave_summarizer)Generates AI-powered summaries from web search results using Brave's summarization API.
Parameters:
key (string, required): Summary key from web search results (use summary: true in web search)
entity_info (boolean, optional): Include entity information (default: false)
inline_references (boolean, optional): Add source URL references (default: false)
Usage: First perform a web search with summary: true, then use the returned summary key with this tool.
brave_place_search)Searches for points of interest (POIs) in a specified geographic area using Brave's Place Search API. Returns rich, structured place data including name, address, opening hours, contact info, ratings, photos, categories, and timezone.
Parameters:
query (string, optional): Query string used to refine the POI search (max 400 chars, 50 words). When omitted, returns general points of interest in the supplied area.
latitude (number, optional): Latitude of the search center (-90 to 90). Typically paired with longitude.
longitude (number, optional): Longitude of the search center (-180 to 180). Typically paired with latitude.
location (string, optional): Location string used as an alternative to latitude/longitude. For US locations prefer the form <city> <state> <country name> (e.g., san francisco ca united states); for non-US locations use <city> <country name> (e.g., tokyo japan).
radius (number, optional): Search radius around the supplied coordinates, in meters. If omitted, the search is performed globally.
count (number, optional): Number of results to return (1-50, default 20).
country (string, optional): Two-letter country code (default US).
search_lang (string, optional): Search language (default en).
ui_lang (string, optional): UI language (default en-US).
units (string, optional): Distance units (metric or imperial, default metric).
safesearch (string, optional): Safe search level (off, moderate, strict, default strict).
spellcheck (boolean, optional): Whether to spellcheck the query (default true).
geoloc (string, optional): Optional geolocation token used to refine results.
Optional request headers:
api-version (string, optional): Brave API version (YYYY-MM-DD)
accept (string, optional): Response media type (application/json or */*)
cache-control (string, optional): Use no-cache to request fresh content
user-agent (string, optional): User agent originating the request
brave_llm_context)Retrieves pre-extracted web content optimized for AI agents, LLM grounding, and RAG pipelines.
Parameters:
query (string, required): Search query (max 400 chars, 50 words)
country (string, optional): Search country code
search_lang (string, optional): Search language code
count (number, optional): Maximum number of search results considered (1-50)
spellcheck (boolean, optional): Enable spell checking
maximum_number_of_urls (number, optional): Maximum number of URLs to include (1-50)
maximum_number_of_tokens (number, optional): Approximate maximum number of context tokens (1024-32768)
maximum_number_of_snippets (number, optional): Maximum number of snippets to include (1-256)
context_threshold_mode (string, optional): Threshold mode ("disabled", "strict", "lenient", "balanced")
maximum_number_of_tokens_per_url (number, optional): Maximum tokens per URL (512-8192)
maximum_number_of_snippets_per_url (number, optional): Maximum snippets per URL (1-100)
goggles (string or array, optional): Goggle URL or definition for custom re-ranking
freshness (string, optional): Time filter ("pd", "pw", "pm", "py", or date range)
enable_local (boolean, optional): Enable local recall
enable_source_metadata (boolean, optional): Include source metadata enrichment
Optional request headers:
x-loc-lat (number, optional): Client latitude (-90 to 90)
x-loc-long (number, optional): Client longitude (-180 to 180)
x-loc-city (string, optional): Client city name
x-loc-state (string, optional): Client state or region code
x-loc-state-name (string, optional): Client state or region name
x-loc-country (string, optional): Client country code
x-loc-postal-code (string, optional): Client postal code
api-version (string, optional): Brave API version (YYYY-MM-DD)
accept (string, optional): Response media type ("application/json" or "/")
cache-control (string, optional): Use no-cache to request fresh content
user-agent (string, optional): User agent originating the request
Sign up for a Brave Search API account
Choose a plan:
Search: The real-time search data your chatbots & agents need to generate answers. Complete search results (URLs, text, news, images, and more), with additional LLM context optimized for AI.
Answers: Summarized, completed answers to any question. Answers grounded on a single search or multiple searches for better accuracy & reduced hallucinations.
Generate your API key from the developer dashboard
The server supports the following environment variables:
BRAVE_API_KEY: Your Brave Search API key (required unless BRAVE_API_KEY_FILE is set)
BRAVE_API_KEY_FILE: Path to a file containing your Brave Search API key. When set, this takes precedence over BRAVE_API_KEY. Useful for Docker secrets and similar mounted-secret setups.
BRAVE_MCP_TRANSPORT: Transport mode ("http" or "stdio", default: "stdio")
BRAVE_MCP_PORT: HTTP server port (default: 8080)
BRAVE_MCP_HOST: HTTP server host (default: "127.0.0.1"). Binds to loopback only by default; set to "0.0.0.0" to expose the server on all interfaces (required inside containers and on Amazon Bedrock AgentCore). Only do this on a trusted network, since the HTTP endpoint is unauthenticated.
BRAVE_MCP_ALLOWED_ORIGINS: Space- or comma-separated list of additional Origin header values permitted for the HTTP transport. Loopback origins are always allowed; browser requests carrying any other Origin are rejected with HTTP 403 to guard against DNS rebinding. Set this when a browser-based client on a real domain needs access.
BRAVE_MCP_ALLOWED_HOSTS: Space- or comma-separated list of hostnames permitted in the Host header of the HTTP transport. Matching is on the hostname only and is case-insensitive; a numeric port in an entry (e.g. mcp.example.com:8080) is accepted but ignored for matching. Optional, opt-in defense-in-depth: when unset (default) the Host header is not validated, so reverse-proxy and custom-domain deployments are unaffected. When set, only loopback hosts and the listed hostnames are accepted; any other Host (including malformed/non-numeric ports) is rejected with HTTP 403.
BRAVE_MCP_LOG_LEVEL: Desired logging level("debug", "info", "notice", "warning", "error", "critical", "alert", or "emergency", default: "info")
BRAVE_MCP_ENABLED_TOOLS: When used, specifies a space-separated whitelist for supported tools
BRAVE_MCP_DISABLED_TOOLS: When used, specifies a space-separated blacklist for supported tools
BRAVE_MCP_STATELESS: HTTP stateless mode (default: "true"). When running on Amazon Bedrock Agentcore, set to "true".
node dist/index.js [options]
Options:
--brave-api-key <string> Brave API key
--brave-api-key-file <string> Path to file containing Brave API key
--transport <stdio|http> Transport type (default: stdio)
--port <number> HTTP server port (default: 8080)
--host <string> HTTP server host (default: 127.0.0.1)
--allowed-origins <origins...> Allowed Origin header values for HTTP transport (DNS rebinding protection)
--allowed-hosts <hosts...> Allowed Host header values for HTTP transport (opt-in DNS rebinding protection)
--logging-level <string> Desired logging level (one of _debug_, _info_, _notice_, _warning_, _error_, _critical_, _alert_, or _emergency_)
--enabled-tools Tools whitelist (only the specified tools will be enabled)
--disabled-tools Tools blacklist (included tools will be disabled)
--stateless <boolean> HTTP Stateless flagAdd this to your claude_desktop_config.json:
{
"mcpServers": {
"brave-search": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "BRAVE_API_KEY", "docker.io/mcp/brave-search"],
"env": {
"BRAVE_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}{
"mcpServers": {
"brave-search": {
"command": "npx",
"args": ["-y", "@brave/brave-search-mcp-server", "--transport", "http"],
"env": {
"BRAVE_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}For quick installation, use the one-click installation buttons below:
For manual installation, add the following to your User Settings (JSON) or .vscode/mcp.json:
{
"inputs": [
{
"password": true,
"id": "brave-api-key",
"type": "promptString",
"description": "Brave Search API Key",
}
],
"servers": {
"brave-search": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "BRAVE_API_KEY", "mcp/brave-search"],
"env": {
"BRAVE_API_KEY": "${input:brave-api-key}"
}
}
}
}{
"inputs": [
{
"password": true,
"id": "brave-api-key",
"type": "promptString",
"description": "Brave Search API Key",
}
],
"servers": {
"brave-search-mcp-server": {
"command": "npx",
"args": ["-y", "@brave/brave-search-mcp-server", "--transport", "stdio"],
"env": {
"BRAVE_API_KEY": "${input:brave-api-key}"
}
}
}
}docker build -t mcp/brave-search:latest .npm install
npm run buildNode.js 22.x or higher
npm
Brave Search API key
Clone the repository:
git clone https://github.com/brave/brave-search-mcp-server.git
cd brave-search-mcp-serverInstall dependencies:
npm installBuild the project:
npm run buildAdd a reference to your local build in claude_desktop_config.json:
{
"mcpServers": {
"brave-search-dev": {
"command": "node",
"args": ["C:\\GitHub\\brave-search-mcp-server\\dist\\index.js"], // Verify your path
"env": {
"BRAVE_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}Build and start the server:
npm run build
node dist/index.jsIn another terminal, start the MCP Inspector:
npx @modelcontextprotocol/inspector node dist/index.jsSTDIO is the default mode. For HTTP mode testing, add --transport http to the arguments in the Inspector UI.
npm run build: Build the TypeScript project
npm run watch: Watch for changes and rebuild
npm run format: Format code with Prettier
npm run format:check: Check code formatting
npm run prepare: Format and build (runs automatically on npm install)
npm run inspector: Launch an instance of MCP Inspector
npm run inspector:stdio: Launch a instance of MCP Inspector, configured for STDIO
For local development with Docker:
docker-compose up --buildSet BRAVE_API_KEY (or BRAVE_API_KEY_FILE) in your shell or a .env file before starting the stack. The default docker-compose.yml also accepts BRAVE_API_KEY_FILE when the path is valid inside the container (for example, from a bind mount or Docker secret).
To avoid putting the API key in an environment variable, you can use Docker Compose secrets. The server reads the key from the path in BRAVE_API_KEY_FILE, which must exist inside the container.
Copy the example secret file and add your key:
cp secrets/brave_api_key.txt.example secrets/brave_api_key.txtStart the stack with the optional secrets override:
docker compose -f docker-compose.yml -f docker-compose.secrets.example.yml up --buildThe override mounts the secret at /run/secrets/brave_api_key and sets BRAVE_API_KEY_FILE accordingly. See docker-compose.secrets.example.yml for the full configuration.
This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.
Performs an image search using the Brave Search API. Helpful for when you need pictures of people, places, things, graphic design ideas, art inspiration, and more. When relaying results in a markdown environment, it may be helpful to include images in the results (e.g., ).
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-200, default 50). Combine this parameter with `offset` to paginate search results. | |
| query | Yes | The user's search query. Query cannot be empty. Limited to 400 characters and 50 words. | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'strict' - Drops all adult content from search results. | strict |
| spellcheck | No | Whether to spellcheck provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| count | Yes | |
| items | Yes | |
| might_be_offensive | Yes | Whether the image might be offensive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide 'openWorldHint: true', which signals non-destructive but no further details. Description adds a markdown display tip but lacks disclosure of rate limits, authentication needs, pagination specifics, or error behavior.
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 concise sentences: first states purpose, second offers usage advice. No wasted words, front-loaded with key information.
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?
Output schema exists, so return values are covered. Description adds practical usage advice (markdown images) and covers the tool's typical context. Could mention pagination via 'offset' (covered in schema) but otherwise complete for a simple search 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 the schema already explains all parameters. The description does not add additional parameter-level meaning beyond what is in the schema, earning a baseline score.
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?
Clearly states action ('performs an image search') and resource ('Brave Search API'). Provides specific examples of use cases (pictures, design, art) and implicitly distinguishes from sibling tools like web, local, news 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?
Gives examples of when to use ('when you need pictures...') but does not explicitly state when not to use or mention alternatives. The sibling list helps, but the description itself lacks direct guidance on differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 to use:
- Grounding answers in fresh, relevant web content (RAG)
- Giving an AI agent ready-to-use page content from a single search call
- Question answering and fact-checking against current sources
- Gathering source material for research without manually fetching pages
- When you need the contents of pages, not just titles, descriptions, and URLs
When relaying results in markdown-supporting environments, cite the source URLs from the "sources" map.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | The maximum number of search results considered to select the LLM context data. The default is 20 and the maximum is 50. | |
| query | Yes | The user's search query term. Query can not be empty. Maximum of 400 characters and 50 words in the query. | |
| accept | No | The default supported media type is application/json. | |
| country | No | The search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | |
| goggles | No | Goggles act as a custom re-ranking on top of Brave's search index. The parameter supports both a url where the Goggle is hosted or the definition of the Goggle. Multiple goggle URLs and/or definitions can be provided in an array. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). | |
| freshness | No | Filters search results by when they were discovered. The following values are supported: 'pd' - Discovered within the last 24 hours. 'pw' - Discovered within the last 7 days. 'pm' - Discovered within the last 31 days. 'py' - Discovered within the last 365 days. 'YYYY-MM-DDtoYYYY-MM-DD' - Timeframe is also supported by specifying the date range e.g. 2022-04-01to2022-07-30. | |
| x-loc-lat | No | The latitude of the client's geographical location in degrees, to provide relevant local results. The latitude must be greater than or equal to -90.0 degrees and less than or equal to +90.0 degrees. | |
| spellcheck | No | Whether to enable spellcheck on the query. | |
| user-agent | No | The user agent originating the request. Brave search can utilize the user agent to provide a different experience depending on the device as described by the string. The user agent should follow the commonly used browser agent strings on each platform. For more information on curating user agents, see RFC 9110. | |
| x-loc-city | No | The generic name of the client city | |
| x-loc-long | No | The longitude of the client's geographical location in degrees, to provide relevant local results. The longitude must be greater than or equal to -180.0 and less than or equal to +180.0 degrees. | |
| api-version | No | The API version to use. This is denoted by the format YYYY-MM-DD. Default is the latest that is available. Read more about API versioning at https://api-dashboard.search.brave.com/documentation/guides/versioning. | |
| search_lang | No | The search language preference. The 2 or more character language code for which the search results are provided. | |
| x-loc-state | No | A code which could be up to three characters, that represent the client's state/region. The region is the first-level subdivision (the broadest or least specific) of the ISO 3166-2 code. | |
| enable_local | No | Whether to enable local recall. Not setting this value means auto-detect and uses local recall if any of the localization headers are provided. | |
| cache-control | No | Brave Search will return cached content by default. To prevent caching set the Cache-Control header to no-cache. This is currently done as best effort. | |
| x-loc-country | No | The two letter country code for the client’s country. For a list of country codes, see ISO 3166-1 alpha-2 | |
| x-loc-state-name | No | The name of the client’s state/region. The region is the first-level subdivision (the broadest or least specific) of the ISO 3166-2 code. | |
| x-loc-postal-code | No | The client’s postal code | |
| context_threshold_mode | No | The mode to use to determine the threshold for including content in context. Default is balanced. | |
| enable_source_metadata | No | Enable source metadata enrichment (site_name, favicon) in the sources attribute of the response. | |
| 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. The default is 8192 and maximum is 32768. | |
| maximum_number_of_snippets | No | Maximum number of different snippets (or chunks of text) to include in LLM context. The default is 50 and maximum is 256. | |
| maximum_number_of_tokens_per_url | No | Maximum number of tokens to include per URL. The default is 4096 and maximum is 8192. | |
| maximum_number_of_snippets_per_url | No | Maximum number of snippets to include per URL. The default is 50 and maximum is 100. |
| Name | Required | Description |
|---|---|---|
| sources | Yes | Metadata for each referenced URL, keyed by URL. Known fields include title, hostname, and age; site_name, favicon, and thumbnail are present when enable_source_metadata is true. Unknown fields are preserved as-is. |
| grounding | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint: true. The description adds value by detailing the return types (text chunks, tables, code blocks, structured data) and mentioning citation of source URLs. No contradictions or missing behavioral traits are evident.
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 bullet points for usage and a clear opening statement. It is moderately long but every sentence adds value. Slight trimming could enhance conciseness.
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 (26 parameters, output schema exists), the description provides a high-level overview and usage context. It does not need to detail return values due to output schema. It covers key aspects but could briefly mention output schema existence.
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 all parameters are documented. The tool description provides no additional parameter meaning beyond what is in the schema. Baseline 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 tool retrieves pre-extracted, relevance-ranked web content via Brave's LLM Context API, optimized for AI agents, LLM grounding, and RAG. It distinguishes itself from traditional search by returning actual page content rather than just links.
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 lists use cases: grounding answers, AI agent content, question answering, fact-checking, research, and when page contents are needed. It implicitly suggests not using when links suffice, but lacks explicit 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brave Local Search API provides enrichments for location search results. Access to this API is available only through the Brave Search API Pro plans; confirm the user's plan before using this tool (if the user does not have a Pro plan, use the brave_web_search tool). Searches for local businesses and places using Brave's Local Search API. Best for queries related to physical locations, businesses, restaurants, services, etc.
Returns detailed information including:
- Business names and addresses
- Ratings and review counts
- Phone numbers and opening hours
Use this when the query implies 'near me', 'in my area', or mentions specific locations (e.g., 'in San Francisco'). This tool automatically falls back to brave_web_search if no local results are found.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-20, default 10). Applies only to web search results (i.e., has no effect on locations, news, videos, etc.) | |
| query | Yes | Search query (max 400 chars, 50 words) | |
| units | No | The measurement units. If not provided, units are derived from search country. | |
| offset | No | Pagination offset (max 9, default 0) | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| goggles | No | Goggles act as a custom re-ranking on top of Brave's search index. The parameter supports both a url where the Goggle is hosted or the definition of the Goggle. Multiple goggle URLs and/or definitions can be provided in an array. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). | |
| summary | No | This parameter enables summary key generation in web search results. This is required for summarizer to be enabled. | |
| ui_lang | No | The language of the UI. The 2 or more character language code for which the search results are provided. | en-US |
| freshness | No | Filters search results by when they were discovered. The following values are supported: 'pd' - Discovered within the last 24 hours. 'pw' - Discovered within the last 7 days. 'pm' - Discovered within the last 31 days. 'py' - Discovered within the last 365 days. 'YYYY-MM-DDtoYYYY-MM-DD' - Timeframe is also supported by specifying the date range e.g. 2022-04-01to2022-07-30. | |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'moderate' - Filters explicit content (e.g., images and videos), but allows adult domains in search results. 'strict' - Drops all adult content from search results. The default value is 'moderate'. | moderate |
| spellcheck | No | Whether to spellcheck the provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| result_filter | No | Result filter (default ['web', 'query']) | |
| extra_snippets | No | A snippet is an excerpt from a page you get as a result of the query, and extra_snippets allow you to get up to 5 additional, alternative excerpts. Only available under Free AI, Base AI, Pro AI, Base Data, Pro Data and Custom plans. | |
| text_decorations | No | Whether display strings (e.g. result snippets) should include decoration markers (e.g. highlighting characters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the Pro plan requirement and fallback behavior. Annotations only provide openWorldHint, which is not contradicted; tool appears read-only. Could mention rate limits or auth specifics, but provides good context.
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, bullet points for return fields, and front-loaded with key access info. No wasted words.
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 covers purpose, restrictions, fallback, typical use cases, and output format (ratings, addresses, etc.), making it 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 coverage is 100%, so parameters are well documented in the schema. The description does not add significant new meaning beyond the schema's descriptions, meeting the baseline.
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 is for location search, listing specific use cases like businesses and restaurants, and distinguishes from sibling tools like brave_web_search and brave_place_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 tells when to use (location queries, 'near me'), when not (non-Pro plan users should use brave_web_search), and mentions automatic fallback to brave_web_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool searches for news articles using Brave's News Search API based on the user's query. Use it when you need current news information, breaking news updates, or articles about specific topics, events, or entities.
When to use:
- Finding recent news articles on specific topics
- Getting breaking news updates
- Researching current events or trending stories
- Gathering news sources and headlines for analysis
Returns a JSON list of news-related results with title, url, and description. Some results may contain snippets of text from the article.
When relaying results in markdown-supporting environments, always cite sources with hyperlinks.
Examples:
- "According to [Reuters](https://www.reuters.com/technology/china-bans/), China bans uncertified and recalled power banks on planes".
- "The [New York Times](https://www.nytimes.com/2025/06/27/us/technology/ev-sales.html) reports that Tesla's EV sales have increased by 20%".
- "According to [BBC News](https://www.bbc.com/news/world-europe-65910000), the UK government has announced a new policy to support renewable energy".| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-50, default 20) | |
| query | Yes | Search query (max 400 chars, 50 words) | |
| offset | No | Pagination offset (max 9, default 0) | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| goggles | No | Goggles act as a custom re-ranking on top of Brave's search index. The parameter supports both a url where the Goggle is hosted or the definition of the Goggle. Multiple goggle URLs and/or definitions can be provided in an array. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). | |
| ui_lang | No | User interface language preferred in response. Usually of the format <language_code>-<country_code>. For more, see RFC 9110. | en-US |
| freshness | No | Filters search results by when they were discovered. The following values are supported: 'pd' - Discovered within the last 24 hours. 'pw' - Discovered within the last 7 Days. 'pm' - Discovered within the last 31 Days. 'py' - Discovered within the last 365 Days. 'YYYY-MM-DDtoYYYY-MM-DD' - Timeframe is also supported by specifying the date range e.g. 2022-04-01to2022-07-30. | |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'moderate' - Filter out explicit content. 'strict' - Filter out explicit and suggestive content. The default value is 'moderate'. | moderate |
| spellcheck | No | Whether to spellcheck provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| extra_snippets | No | A snippet is an excerpt from a page you get as a result of the query, and extra_snippets allow you to get up to 5 additional, alternative excerpts. Only available under Free AI, Base AI, Pro AI, Base Data, Pro Data and Custom plans. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include title and openWorldHint (unclear). The description adds behavioral info: returns JSON list with title, url, description, and snippets. No contradictions, but no disclosure on rate limits or authentication. Since annotations are minimal, the description provides adequate but not rich behavioral context.
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 somewhat lengthy but well-structured into sections (purpose, when to use, result format, examples). It is front-loaded with the core purpose. Could be slightly more concise, but generally clear and organized.
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 11 parameters, no output schema, and no nested objects, the description explains the return format (JSON list with title, url, description, snippets) and provides usage guidance. It covers essential context but could mention pagination more explicitly (offset and count).
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 covers 100% of parameters with descriptions, so the description does not need to add much. It summarizes query and result format, but adds no new parameter details beyond the schema. Baseline 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 it searches for news articles using Brave's News Search API. It distinguishes from sibling tools (other Brave searches) by specifying 'news' and providing usage examples, making the purpose specific and 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 includes a 'When to use' list that explicitly guides the agent on appropriate scenarios (e.g., finding recent news, breaking updates). It also provides markdown citation examples. While it lacks explicit 'when not to use', the positive guidance is strong and contextually clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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's shape.
When to use:
- POIs near coordinates or a named area (e.g. "coffee shops in Paris") -> 'results', each with structured business data (postal address, hours, contact, ratings, photos, categories, timezone).
- Browsing general POIs (omit 'query'; supply 'latitude'+'longitude' or 'location').
- Disambiguating a bare city name (e.g. "springfield") -> 'cities'.
- Resolving a specific address (e.g. "350 5th avenue" with NYC coords) -> 'addresses' (often plus 'streets').
- Looking up a street by name (e.g. "michigan avenue" with Chicago coords) -> 'streets'.
Inputs:
- Anchor the search via 'latitude'+'longitude' or 'location' (or both). With neither, 'query' is required.
- 'addresses' / 'streets' only surface when the query is address-/street-shaped AND geographically anchored.
- 'location' format: 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.
- 'count' caps results (max 50, default 20). 'radius' (meters) biases toward closer results; it does NOT hard-limit the search area.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results to return. Maximum is 50. Default is 20. | |
| query | No | Query string. Shape influences the response: POI-like queries -> `results`; bare/ambiguous city names -> `cities`; address- or street-shaped queries with a geographic anchor -> `addresses` and/or `streets`. If omitted, returns general POIs in the supplied area. | |
| units | No | Units of measurement for distance values. Defaults to 'metric'. | |
| accept | No | The default supported media type is application/json. | |
| 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 -- the API may still return more distant results. If omitted, the search is performed globally. | |
| country | No | Two-letter country code (ISO 3166-1 alpha-2) used to scope the search. Defaults to 'US'. | |
| ui_lang | No | User interface language for the response, usually of the form '<language>-<region>'. Defaults to 'en-US'. | |
| latitude | No | Latitude of the geographical coordinates around which to search, in degrees (-90 to 90). Typically paired with `longitude`. | |
| location | No | Location string to search around, used as an alternative to `latitude` and `longitude`. For US locations prefer the form '<city> <state> <country name>' (e.g. 'san francisco ca united states'); for non-US locations use '<city> <country name>' (e.g. 'tokyo japan'). No commas or special characters needed; capitalization does not matter. | |
| longitude | No | Longitude of the geographical coordinates around which to search, in degrees (-180 to 180). Typically paired with `latitude`. | |
| safesearch | No | Safe search level for the query results. 'off' - No filtering. 'moderate' - Filter out explicit content. 'strict' - Filter out explicit and suggestive content. Defaults to 'strict'. | |
| spellcheck | No | Whether to apply spellcheck before executing the search. Defaults to true. | |
| user-agent | No | The user agent originating the request. Brave Search can utilize the user agent to provide a different experience depending on the device as described by the string. The user agent should follow the commonly used browser agent strings on each platform. For more information on curating user agents, see RFC 9110. | |
| api-version | No | The API version to use. This is denoted by the format YYYY-MM-DD. Default is the latest that is available. Read more about API versioning at https://api-dashboard.search.brave.com/documentation/guides/versioning. | |
| search_lang | No | Language for the search results. Defaults to 'en'. | |
| cache-control | No | Brave Search will return cached content by default. To prevent caching set the Cache-Control header to no-cache. This is currently done as best effort. |
| Name | Required | Description |
|---|---|---|
| type | Yes | Top-level response discriminator. Always "locations" for Place Search. |
| query | No | |
| cities | No | City matches for the query. Typically populated when the query is a bare or ambiguous city name (e.g. "springfield", "san francisco"). |
| results | No | Points of interest matching the search. Populated for POI-shaped queries. |
| streets | No | Street matches. Typically populated when the query is a street name AND is geographically anchored via `latitude`+`longitude` or a specific `location`. |
| location | No | The search area as resolved by the API (e.g. coordinates + city name). Useful for confirming the API interpreted the input as expected and for grounding follow-up queries. |
| addresses | No | Address matches. Typically populated when the query is a street + number AND is geographically anchored via `latitude`+`longitude` or a specific `location`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that radius is a bias not a hard limit and explains location format. However, it does not address rate limits, authentication, or other behavioral nuances, missing some transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and front-loads the main purpose. While slightly lengthy, every sentence serves to clarify behavior or usage, with no wasted words.
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 17 parameters and output schema existence, the description covers essential usage patterns and constraints. It lacks error handling details but provides sufficient context for an AI agent to select and invoke the tool effectively.
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 adds significant value by explaining inter-parameter dependencies (e.g., anchor required for addresses/streets, query behavior when omitted) and clarifying the radius's non-hard-limitation, going 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Searches Brave's Place Search API') and clearly differentiates the various result types (POIs, cities, addresses, streets, location) based on query shape, making the tool's 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?
A dedicated 'When to use' section provides clear scenarios for each result type. It explains input requirements (anchor via lat/long or location) and constraints (addresses/streets require specific query shape), though it does not explicitly compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves AI-generated summaries of web search results using Brave's Summarizer API. This tool processes search results to create concise, coherent summaries of information gathered from multiple sources.
When to use:
- When you need a concise overview of complex topics from multiple sources
- For quick fact-checking or getting key points without reading full articles
- When providing users with summarized information that synthesizes various perspectives
- For research tasks requiring distilled information from web searches
Returns a text summary that consolidates information from the search results. Optional features include inline references to source URLs and additional entity information.
Requirements: Must first perform a web search using brave_web_search with summary=true parameter. Requires a Pro AI subscription to access the summarizer functionality.| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key is equal to value of field key as part of the Summarizer response model. | |
| entity_info | No | Returns extra entities info with the summary response. | |
| inline_references | No | Adds inline references to the summary response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint: true. The description adds key behavioral context: it requires a Pro AI subscription, depends on prior brave_web_search, and returns a text summary with optional features. No contradictions with 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?
The description is well-structured with a clear first sentence stating purpose, followed by usage guidelines, return description, and requirements. It is slightly lengthy but every sentence adds value, so concise enough.
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 3 parameters, no output schema, and minimal annotations, the description is thorough. It covers prerequisites, subscription requirements, return format, and optional features. Missing nothing essential for tool selection and invocation.
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 baseline is 3. The tool description repeats the optionality of entity_info and inline_references but does not add new meaning beyond the schema. Minor clarification but insufficient to raise score.
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 AI-generated summaries of web search results, specifying the verb (retrieves) and resource (summaries). It distinguishes from sibling search tools by emphasizing the summarization function and prerequisite dependency on 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?
Explicit 'When to use:' bullet points list specific scenarios. It also states requirements: must first call brave_web_search with summary=true and need a Pro AI subscription, providing clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for videos using Brave's Video Search API and returns structured video results with metadata.
When to use:
- When you need to find videos related to a specific topic, keyword, or query.
- Useful for discovering video content, getting video metadata, or finding videos from specific creators/publishers.
Returns a JSON list of video-related results with title, url, description, duration, and thumbnail_url.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-50, default 20). Combine this parameter with `offset` to paginate search results. | |
| query | Yes | The user's search query. Query cannot be empty. Limited to 400 characters and 50 words. | |
| offset | No | Pagination offset (max 9, default 0). Combine this parameter with `count` to paginate search results. | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| ui_lang | No | User interface language preferred in response. Usually of the format <language_code>-<country_code>. For more, see RFC 9110. | en-US |
| freshness | No | Filters search results by when they were discovered. The following values are supported: 'pd' - Discovered within the last 24 hours. 'pw' - Discovered within the last 7 days. 'pm' - Discovered within the last 31 days. 'py' - Discovered within the last 365 days. 'YYYY-MM-DDtoYYYY-MM-DD' - timeframe is also supported by specifying the date range (e.g. '2022-04-01to2022-07-30'). | |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'moderate' - Filter out explicit content. 'strict' - Filter out explicit and suggestive content. The default value is 'moderate'. | moderate |
| spellcheck | No | Whether to spellcheck provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint=true, indicating external data access. The description adds return format details (title, url, description, etc.) but does not discuss rate limits, authentication, or potential side effects. It provides moderate transparency 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?
The description is concise and well-structured, with a clear opening sentence, a bulleted usage section, and a brief return format note. No unnecessary content, and every sentence adds 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?
The description adequately covers the main purpose and return format for a video search tool with 9 parameters. However, it lacks details on error handling, pagination behavior beyond what the schema provides, and more comprehensive output structure. Still, it is mostly complete 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?
The input schema already covers all 9 parameters with descriptions (100% coverage). The tool description does not add substantive parameter-level information beyond what the schema provides, so a baseline score 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 it searches for videos using Brave's Video Search API, specifying the resource (videos) and the action (searches). It distinguishes itself from sibling tools like brave_web_search and brave_image_search by explicitly 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.
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 provides clear context for video discovery, but does not explicitly state when not to use it or list alternatives among siblings. The context is sufficient given the distinct purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs web searches using the Brave Search API and returns comprehensive search results with rich metadata.
When to use:
- General web searches for information, facts, or current topics
- Location-based queries (restaurants, businesses, points of interest)
- News searches for recent events or breaking stories
- Finding videos, discussions, or FAQ content
- Research requiring diverse result types (web pages, images, reviews, etc.)
Returns a JSON list of web results with title, description, and URL.
When the "results_filter" parameter is empty, JSON results may also contain FAQ, Discussions, News, and Video results.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-20, default 10). Applies only to web search results (i.e., has no effect on locations, news, videos, etc.) | |
| query | Yes | Search query (max 400 chars, 50 words) | |
| units | No | The measurement units. If not provided, units are derived from search country. | |
| offset | No | Pagination offset (max 9, default 0) | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| goggles | No | Goggles act as a custom re-ranking on top of Brave's search index. The parameter supports both a url where the Goggle is hosted or the definition of the Goggle. Multiple goggle URLs and/or definitions can be provided in an array. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). | |
| summary | No | This parameter enables summary key generation in web search results. This is required for summarizer to be enabled. | |
| ui_lang | No | The language of the UI. The 2 or more character language code for which the search results are provided. | en-US |
| freshness | No | Filters search results by when they were discovered. The following values are supported: 'pd' - Discovered within the last 24 hours. 'pw' - Discovered within the last 7 days. 'pm' - Discovered within the last 31 days. 'py' - Discovered within the last 365 days. 'YYYY-MM-DDtoYYYY-MM-DD' - Timeframe is also supported by specifying the date range e.g. 2022-04-01to2022-07-30. | |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'moderate' - Filters explicit content (e.g., images and videos), but allows adult domains in search results. 'strict' - Drops all adult content from search results. The default value is 'moderate'. | moderate |
| spellcheck | No | Whether to spellcheck the provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| result_filter | No | Result filter (default ['web', 'query']) | |
| extra_snippets | No | A snippet is an excerpt from a page you get as a result of the query, and extra_snippets allow you to get up to 5 additional, alternative excerpts. Only available under Free AI, Base AI, Pro AI, Base Data, Pro Data and Custom plans. | |
| text_decorations | No | Whether display strings (e.g. result snippets) should include decoration markers (e.g. highlighting characters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include 'openWorldHint: true', so the description carries more burden. It discloses return format (JSON list with title, description, URL) and that results can vary based on 'results_filter'. It doesn't discuss rate limits, authentication, or any side effects beyond consumption of the API. Adequate but not thorough.
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 concise, well-structured with a main sentence, bullet points for use cases, and a note about 'results_filter'. No redundant information.
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 web search tool with 15 parameters and no output schema, the description covers the purpose, use cases, and key behavioral notes. It could mention that it requires network access (implied by openWorldHint) or pagination behavior, but overall it's fairly 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 coverage is 100%, so parameters are fully described in the schema. The description adds minimal extra meaning, only noting the effect of 'results_filter' on result types. 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 it performs web searches using Brave Search API and lists diverse use cases (general, location, news, videos). It distinguishes from sibling tools by mentioning that when 'results_filter' is empty, results may include FAQ, Discussions, News, and Video, which are normally handled by separate siblings.
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 'When to use' section provides explicit scenarios. It also notes behavior when 'results_filter' is empty, implying when to expect additional result types. However, it does not explicitly mention when NOT to use this tool or list alternatives like brave_local_search or brave_video_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.1.0brave_image_searchbrave_llm_contextbrave_local_searchbrave_news_searchbrave_place_searchbrave_summarizerbrave_video_searchbrave_web_searchMost tools target distinct media types or functionalities (web, local, video, image, news, summarizer, place, LLM context). However, brave_local_search and brave_place_search both handle location-based queries, and brave_summarizer and brave_llm_context both provide post-search processing, creating minor potential for confusion.
All tools share the 'brave_' prefix, and most follow a 'brave_<medium>_search' pattern (web, local, video, image, news, place). Two tools (brave_summarizer, brave_llm_context) use noun phrases instead of verbs, introducing slight inconsistency but still clearly related.
Eight tools is an ideal size for a search API server, covering general web search, specialized verticals (local, video, image, news), and advanced AI features (summarization, LLM context). The count is well-scoped without unnecessary bloat.
The tool set covers all major search verticals (web, local, video, image, news) and includes advanced capabilities for summarization and content retrieval. There are no obvious gaps for the stated purpose of providing a comprehensive search interface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Brave Search MCP — independent web index (no Google/Bing dependency)
Visit https://brave.com/search/api/ for a free API key. Search the web, local businesses, images,…
Scrape, crawl and search the web for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/oki602960/brave-search-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server