Brave Search MCP
The Brave Search MCP Server integrates with the Brave Search API to provide various search capabilities:
Web Search: Perform general searches across diverse web sources (maximum 20 results per request)
Image Search: Find web images based on specific queries (maximum 3 results per request)
News Search: Retrieve news articles and trending topics (maximum 20 results per request)
Video Search: Search for video content and tutorials (maximum 20 results per request)
Local Search: Find businesses, restaurants, and points of interest nearby (maximum 20 results per request, falls back to web search if no local results are found)
Provides Web Search, Local Points of Interest Search, Video Search, Image Search and News Search capabilities through the Brave Search API, allowing users to retrieve various types of search results.
Click on "Deploy 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 MCPfind recent news about AI advancements"
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.
Brave Search MCP Server
An MCP Server implementation that integrates the Brave Search API, providing, Web Search, Local Points of Interest Search, Video Search, Image Search, News Search and LLM Context Search capabilities
Features
Web Search: Perform a regular search on the web
Image Search: Search the web for images.
News Search: Search the web for news
Video Search: Search the web for videos
Local Points of Interest Search: Search for local physical locations, businesses, restaurants, services, etc
LLM Context Search: Fetch and extract full web page content optimized for reading and synthesizing sources
Related MCP server: Brave Search With Proxy
Tools
brave_web_search
Execute web searches using Brave's API
Inputs:
query(string): The term to search the internet forcount(number, optional): The number of results to return (max 20, default 10)offset(number, optional, default 0): The offset for paginationfreshness(enum, optional): Filters search results by when they were discoveredThe 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: Custom date range (e.g., 2022-04-01to2022-07-30)
brave_image_search
Get images from the web relevant to the query
Inputs:
query(string): The term to search the internet for images ofcount(number, optional): The number of images to return (max 50, default 10)
brave_news_search
Searches the web for news
Inputs:
query(string): The term to search the internet for news articles, trending topics, or recent eventscount(number, optional): The number of results to return (max 20, default 10)offset(number, optional, default 0): The zero-based offset for pagination (max 9)freshness(enum, optional): Filters search results by when they were discoveredThe 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: Custom date range (e.g., 2022-04-01to2022-07-30)
brave_local_search
Search for local businesses, services and points of interest
Falls back to brave_web_search on the initial page if no location results are found
Inputs:
query(string): Local search termcount(number, optional): The number of results to return (max 20, default 5)offset(number, optional, default 0): The zero-based offset for pagination (max 9)
brave_video_search
Search the web for videos
Inputs:
query: (string): The term to search for videoscount: (number, optional): The number of videos to return (max 20, default 10)offset(number, optional, default 0): The zero-based offset for pagination (max 9)freshness(enum, optional): Filters search results by when they were discoveredThe 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: Custom date range (e.g., 2022-04-01to2022-07-30)
brave_llm_context_search
Pre-extracted web content optimized for AI agents, LLM grounding, and RAG pipelines.
Uses Brave's
balancedcontext threshold mode incompactmode and disables Brave relevance filtering infullmode.Inputs:
query(string): The search query. Maximum 400 characters and 50 words.url(string, optional): Optional URL to target. When provided, query and URL are combined for retrieval and only snippets from this exact URL are returned.count(number, optional, default 8): The maximum number of search results considered. Minimum 1, maximum 50.maximumNumberOfUrls(number, optional, default 8): The maximum number of URLs to include in the response. Minimum 1, maximum 50.maximumNumberOfTokens(number, optional, default 2048): The approximate maximum number of tokens in the returned context. Minimum 1024, maximum 32768.maximumNumberOfSnippets(number, optional, default 16): The maximum number of snippets across all URLs. Minimum 1, maximum 100.maximumNumberOfTokensPerUrl(number, optional, default 512): The maximum number of tokens per URL. Minimum 512, maximum 8192.maximumNumberOfSnippetsPerUrl(number, optional, default 2): The maximum number of snippets per URL. Minimum 1, maximum 100.responseMode(enum, optional, defaultcompact):compactapplies Brave'sbalancedrelevance filtering plus local snippet filtering/truncation.fulldisables Brave's relevance filtering and returns raw snippets without local filtering or truncation.maxSnippetChars(number, optional, default 400): Maximum characters per snippet in compact mode. Minimum 80, maximum 4000.maxOutputChars(number, optional, default 8000): Approximate maximum serialized response size in compact mode. Minimum 1000, maximum 100000.
OpenAI Apps & MCP Apps Support
There is now support for OpenAI Apps and MCP Apps in this MCP Server. When UI mode is enabled for each tool there is a corresponding UI widget that let's you control what gets added to the model's context. See the directions in usage with ChatGPT section.
Configuration
Getting an API Key
Sign up for a Brave Search API account
Choose a plan
Generate your API key from the developer dashboard
Runtime modes
By default the MCP server runs in stdio mode.
BRAVE_API_KEY="your_key_here" npx -y brave-search-mcpTo enable Streamable HTTP mode:
BRAVE_API_KEY="your_key_here" npx -y brave-search-mcp --httpBy default the server listens on port 3001. The URL is:
http://0.0.0.0:3001/mcpThere are two configuration modes:
Env mode:
BRAVE_MCP_CONFIGis unset. Feature toggles come from environment variables exactly as in previous releases.File mode:
BRAVE_MCP_CONFIG=/path/to/config.tomlis set. The TOML file becomes the single source of truth for feature settings, and overlapping feature env vars are ignored with warnings.
Environment-only settings
These settings are always read from the process environment, regardless of mode:
BRAVE_API_KEY(required): Brave Search API key.PORT(optional): HTTP port (default:3001).HOST(optional): Interface to bind to (default:0.0.0.0).BRAVE_MCP_CONFIG(optional): Absolute or relative path to a TOML config file for feature settings.
Env mode feature settings
When BRAVE_MCP_CONFIG is not set, these feature env vars are supported:
ALLOWED_HOSTS(HTTP mode only): Comma-separated list of allowed hostnames for Host header validation.Example:
ALLOWED_HOSTS=localhost,127.0.0.1,my-app.ngrok-free.appUse hostnames only (no scheme/path), e.g.
my-app.ngrok-free.appnothttps://my-app.ngrok-free.app/mcp
BRAVE_MCP_POLICY_FILE: JSON policy file path.BRAVE_MCP_POLICY_REDACT:trueto redact matched text instead of blocking it.BRAVE_MCP_REQUEST_LIMIT: Positive integer request cap.BRAVE_MCP_WINDOW_SECONDS: Non-negative integer rolling window size.BRAVE_MCP_COOLDOWN_SECONDS: Non-negative integer cooldown after the limit is exceeded.BRAVE_MCP_AUDIT_LOG:trueto emit audit logs.BRAVE_MCP_AUDIT_LOG_RAW:trueto include raw query text in audit logs.BRAVE_MCP_REQUIRE_JUSTIFICATION:trueto reject tool calls without ajustificationstring.
Examples:
# Local only
HOST=127.0.0.1 ALLOWED_HOSTS=localhost,127.0.0.1 BRAVE_API_KEY="your_key_here" npx -y brave-search-mcp --http# Local with ngrok tunnel
HOST=127.0.0.1 ALLOWED_HOSTS=localhost,127.0.0.1,my-app.ngrok-free.app BRAVE_API_KEY="your_key_here" npx -y brave-search-mcp --http --uiFile mode (BRAVE_MCP_CONFIG)
When BRAVE_MCP_CONFIG is set, the file controls feature configuration, including the HTTP host allowlist.
[auth]
httpApiKey = "sk-..."
requireAuth = true
callerId = "team-a"
[auth.jwt]
jwksUri = "https://idp.example.com/.well-known/jwks.json"
audience = "brave-search-mcp"
clockSkewSeconds = 30
[auth.oauth]
issuer = "https://idp.example.com"
audience = "brave-search-mcp"
clientId = "client-123"
clientSecret = "super-secret"
verifyStrategy = "jwks"
[audit]
enabled = true
logRaw = false
hmacSecret = "audit-secret"
[policy]
file = "/etc/brave-mcp/policy.json"
redact = false
[guardrail]
requestLimit = 100
windowSeconds = 60
cooldownSeconds = 10
requireJustification = false
[server]
allowedHosts = [
"localhost",
"127.0.0.1",
"my-app.ngrok-free.app",
]Notes:
BRAVE_API_KEY,PORT, andHOSTremain environment-only even in file mode.If you set overlapping feature env vars such as
BRAVE_MCP_REQUEST_LIMITorALLOWED_HOSTSalongsideBRAVE_MCP_CONFIG, startup warns that they are being ignored.Unknown TOML keys also emit warnings so typos like
[guardrails]are visible before you debug runtime behavior.
To validate a config file without starting the server, use the packaged entrypoint after building the app workspace:
pnpm -C apps/brave-search-mcp run build
node apps/brave-search-mcp/dist/index.js --check-config ./apps/brave-search-mcp/test/fixtures/config.valid.tomlTo run the built local entrypoint in file mode:
pnpm -C apps/brave-search-mcp run build
BRAVE_API_KEY="your_key_here" BRAVE_MCP_CONFIG="$PWD/apps/brave-search-mcp/test/fixtures/config.valid.toml" node apps/brave-search-mcp/dist/index.js --httpUsage with ChatGPT
The Brave Search MCP Server can be used with the web UI of ChatGPT. It takes a few steps.
1. Enable Developer Mode in ChatGPT
Settings → Apps → Advanced settings → Developer mode
Additional instructions here
2. Run the Brave Search MCP in HTTP mode and UI mode
BRAVE_API_KEY="your_key_here" npx -y brave-search-mcp --http --ui3. Create a local tunnel to expose the MCP Server to ChatGPT
Sign up and configure ngrok, the free plan works.
ngrok http 3001Take note of the forwarding URL.
...
Forwarding https://john-joe-asdf.ngrok-free.dev -> http://localhost:3001
...4. Add Brave Search MCP as a Connector to ChatGPT
Click Apps
Click Create Apps
Fill out the form using the URL from step 3 as the MCP Server URL, but add /mcp.
https://john-joe-asdf.ngrok-free.dev/mcpFor Authentication, select 'No Auth'
Tick the checkbox for 'I understand and want to continue'
Then click Create.
5. Using the Brave Search MCP Server
In the ChatGPT UI, click the '+' button, scroll to '...more', select the newly created Brave Search app, and enter your query.
Usage with Claude Code
For Claude Code users, run this command:
Windows:
claude mcp add-json brave-search '{"command":"cmd","args":["/c","npx","-y","brave-search-mcp"],"env":{"BRAVE_API_KEY":"YOUR_API_KEY_HERE"}}'Linux/macOS:
claude mcp add-json brave-search '{"command":"npx","args":["-y","brave-search-mcp"],"env":{"BRAVE_API_KEY":"YOUR_API_KEY_HERE"}}'Replace YOUR_API_KEY_HERE with your actual Brave Search API key.
Usage with Claude Desktop
MCP Bundle (MCPB)
Download the
mcpbfile from the ReleasesOpen it with Claude Desktop or Go to File -> Settings -> Extensions and drag the .mcpb file to the window to install it
Docker
Clone the repo
Build the image from the repo root
docker build -t brave-search-mcp:latest -f apps/brave-search-mcp/Dockerfile .Run it directly if you want HTTP mode:
docker run --rm -p 3001:3001 -e BRAVE_API_KEY="YOUR_API_KEY_HERE" brave-search-mcp:latest --httpAdd this to your
claude_desktop_config.jsonfor stdio mode:
{
"mcp-servers": {
"brave-search": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"BRAVE_API_KEY",
"brave-search-mcp"
],
"env": {
"BRAVE_API_KEY": "YOUR API KEY HERE"
}
}
}
}NPX
Add this to your claude_desktop_config.json:
{
"mcp-servers": {
"brave-search": {
"command": "npx",
"args": [
"-y",
"brave-search-mcp"
],
"env": {
"BRAVE_API_KEY": "YOUR API KEY HERE"
}
}
}
}Usage with LibreChat
Add this to librechat.yaml
brave-search:
command: sh
args:
- -c
- BRAVE_API_KEY=API KEY npx -y brave-search-mcpContributing
Contributions are welcome! See CONTRIBUTING.md for development setup, monorepo structure, and release instructions. For UI build workflow details, including the entrypoint orchestrator, see UI Build Orchestrator.
Disclaimer
This library is not officially associated with Brave Software. It is a third-party implementation of the Brave Search API with a MCP Server.
License
This project is licensed under the GNU General Public License v3.0 - see the LICENSE file for details.
Available Tools
5 toolsbrave_image_searchB
A tool for searching the web for images using the Brave Search API.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | The number of images to search for, minimum 1, maximum 3 | |
| searchTerm | Yes | The term to search the internet for images of |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for 'searching the web for images using the Brave Search API,' which implies a read-only operation but does not clarify aspects like rate limits, authentication needs, or what happens if no results are found. For a tool with zero annotation coverage, this is insufficient, as it lacks details on behavioral traits beyond the basic purpose.
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, efficient sentence: 'A tool for searching the web for images using the Brave Search API.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence earns its place by specifying the action, resource, and method.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects (e.g., rate limits, error handling) and usage guidelines relative to siblings. Without an output schema, it doesn't explain return values, but the schema handles parameters well. This results in a score of 3, indicating it meets the minimum viable threshold but has clear gaps.
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 has 100% description coverage, with clear documentation for both parameters ('searchTerm' and 'count'), including defaults and constraints. The description does not add any semantic details beyond what the schema provides (e.g., it doesn't explain parameter interactions or usage examples). According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3, which is appropriate here.
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's purpose: 'searching the web for images using the Brave Search API.' It specifies the verb ('searching'), resource ('images'), and method ('using the Brave Search API'), which is more informative than just restating the name. However, it does not explicitly distinguish this tool from its sibling tools (e.g., brave_web_search, brave_video_search) beyond implying it's for images, which is why it scores 4 instead of 5.
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 its siblings (brave_local_search, brave_news_search, brave_video_search, brave_web_search). It mentions 'searching the web for images,' which implies a general image search context, but offers no explicit when/when-not instructions or alternatives. This lack of comparative guidance results in a score of 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brave_local_searchA
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' or mentions specific locations. Automatically falls back to web search if no local results are found.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | The number of results to return, minimum 1, maximum 20 | |
| query | Yes | Local search query (e.g. 'pizza near Central Park') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: the fallback mechanism to web search, the types of information returned (business details, ratings, contact info), and the context of local/physical searches. It doesn't mention rate limits, authentication needs, or error handling, but provides substantial operational 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 efficiently structured with a clear purpose statement, usage guidelines, and a bulleted list of return details. Every sentence adds value without redundancy, and it's front-loaded with the core functionality.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is quite complete—it covers purpose, usage, behavior, and return details. It lacks output format specifics (e.g., structure of returned data) and error handling, but compensates well with clear operational context.
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 baseline is 3. The description adds minimal parameter semantics beyond the schema—it provides an example query ('pizza near Central Park') that reinforces the schema's guidance but doesn't explain parameter interactions or additional constraints.
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 specific action ('Searches for local businesses and places') using a specific resource ('Brave's Local Search API'), and distinguishes it from siblings by specifying it's for 'physical locations, businesses, restaurants, services' rather than images, news, videos, or general web content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when the query implies 'near me' or mentions specific locations') and mentions an alternative behavior ('Automatically falls back to web search if no local results are found'), though it doesn't explicitly name sibling alternatives like '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_searchA
Searches for news articles using the Brave Search API. Use this for recent events, trending topics, or specific news stories. Returns a list of articles with titles, URLs, and descriptions. Maximum 20 results per request.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | The number of results to return, minimum 1, maximum 20 | |
| query | Yes | The term to search the internet for news articles, trending topics, or recent events |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: 'Returns a list of articles with titles, URLs, and descriptions' (output format) and 'Maximum 20 results per request' (rate/limit constraint). However, it doesn't mention authentication needs, error handling, pagination, or whether results are cached/fresh. For a search tool with zero annotation coverage, this is adequate but leaves gaps.
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 appropriately sized and front-loaded: first sentence states purpose, second gives usage context, third describes output, fourth sets constraints. Every sentence earns its place with no wasted words. It efficiently conveys essential information in four concise sentences.
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 moderate complexity (search with parameters), 100% schema coverage, no annotations, and no output schema, the description is reasonably complete. It covers purpose, usage context, output format, and a key constraint. However, without an output schema, it could benefit from more detail on the article structure (e.g., publication date, source) or error scenarios.
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 fully documents both parameters (query and count). The description adds no additional parameter semantics beyond what's in the schema. It mentions 'Maximum 20 results per request' which aligns with the schema's count maximum, but doesn't provide new syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Searches for news articles using the Brave Search API' (verb+resource). It distinguishes from siblings by specifying 'news articles' rather than images, local results, videos, or general web content. However, it doesn't explicitly contrast with siblings like 'Use this instead of brave_web_search for news-specific 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 provides clear context for when to use: 'for recent events, trending topics, or specific news stories.' This gives practical guidance. However, it doesn't explicitly state when NOT to use this tool or name alternatives among the sibling tools (e.g., 'Use brave_web_search for general web results instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brave_video_searchA
Searches for videos using the Brave Search API. Use this for video content, tutorials, or any media-related queries. Returns a list of videos with titles, URLs, and descriptions. Maximum 20 results per request.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | The number of results to return, minimum 1, maximum 20 | |
| query | Yes | The term to search the internet for videos of |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the return format ('list of videos with titles, URLs, and descriptions') and rate limiting ('Maximum 20 results per request'), but doesn't mention authentication requirements, error handling, or pagination 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?
The description is efficiently structured in three sentences: purpose, usage context, and behavioral constraints. Every sentence adds value with no redundant information, making it appropriately sized 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?
For a search tool with no annotations and no output schema, the description provides good coverage of purpose, usage context, and key behavioral constraints. However, it could be more complete by explicitly mentioning the API source (Brave Search) and potential limitations like authentication or error scenarios.
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 fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Searches for videos'), resource ('using the Brave Search API'), and distinguishes it from sibling tools by specifying it's for 'video content, tutorials, or any media-related queries' rather than images, local results, news, or web pages.
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 clear context for when to use this tool ('for video content, tutorials, or any media-related queries'), but doesn't explicitly mention when not to use it or name specific alternatives among the sibling tools like 'brave_image_search' or '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_web_searchA
Performs a web search using the Brave Search API, ideal for general queries, and online content. Use this for broad information gathering, recent events, or when you need diverse web sources. Maximum 20 results per request
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | The number of results to return, minimum 1, maximum 20 | |
| offset | No | The offset for pagination, minimum 0 | |
| query | Yes | The term to search the internet for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the maximum results per request (20) and ideal use cases, but doesn't cover other behavioral aspects like rate limits, authentication needs, error handling, or response format details.
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 efficiently structured in two sentences with zero waste - the first establishes purpose and ideal use cases, the second provides a key behavioral constraint (maximum results). Every element earns its place without redundancy.
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 search tool with no annotations and no output schema, the description provides adequate purpose and usage guidance but lacks details about response format, error conditions, or authentication requirements that would be helpful for an AI agent to use it 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 description coverage is 100%, so the schema already fully documents all three parameters (query, count, offset). The description doesn't add any parameter-specific meaning beyond what's in the schema, maintaining the baseline score of 3 for good 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 the specific action ('performs a web search') and resource ('using the Brave Search API'), distinguishing it from siblings like image, local, news, and video search by specifying it's for 'general queries' and 'online content' rather than specialized media types.
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 clear context for when to use this tool ('broad information gathering, recent events, or when you need diverse web sources'), but it doesn't explicitly state when NOT to use it or name specific alternatives among its siblings (e.g., use brave_news_search for news-specific results).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v1.0.0- First observed
brave_image_search - First observed
brave_local_search - First observed
brave_news_search - First observed
brave_video_search - First observed
brave_web_search
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose targeting different content types: images, local businesses, news articles, videos, and general web content. The descriptions explicitly differentiate use cases (e.g., 'near me' for local search, 'recent events' for news), eliminating any ambiguity between tools.
All tool names follow a consistent 'brave_[content_type]_search' pattern, using snake_case uniformly. This predictable naming scheme makes it easy to identify the tool's function and ensures no confusion from mixed conventions.
With 5 tools, this server is well-scoped for its purpose of providing specialized search capabilities across different content types. Each tool earns its place by covering distinct search domains, avoiding both redundancy and excessive fragmentation.
The tool set comprehensively covers the search domain by addressing all major content types: images, local information, news, videos, and general web content. There are no obvious gaps, as agents can handle any search query by selecting the appropriate specialized or general tool.
Maintenance
Related MCP Connectors
Visit https://brave.com/search/api/ for a free API key. Search the web, local businesses, images,…
Brave Search MCP — independent web index (no Google/Bing dependency)
Serper MCP — wraps the Serper Google Search API (serper.dev)
Related MCP Servers
- -licenseNot gradedqualityAmaintenanceAn MCP server implementation that integrates the Brave Search API, providing both web and local search capabilities.13,797 npm90,399MIT
- AlicenseAqualityDmaintenanceAn MCP server for integrating with the Brave Search API, and it supports HTTP proxying.218 npm3JavaScriptMIT

Brave Search MCP Serverofficial
AlicenseAqualityAmaintenanceAn MCP implementation that integrates the Brave Search API, providing comprehensive search capabilities including web, local business, image, video, news searches, and AI-powered summarization.8810,280 npm1,445MIT- AlicenseBqualityDmaintenanceEnables web search capabilities through the Brave Search API, including web search, local POI lookups, and rich search results retrieval for MCP-compatible clients.422 npmMIT