Brave Search MCP
Brave Search MCP 服务器
集成Brave Search API 的MCP 服务器实现,提供网页搜索、本地兴趣点搜索、视频搜索、图片搜索和新闻搜索功能
特征
网络搜索:在网络上进行常规搜索
图片搜索:在网络上搜索图片。图片搜索结果将作为资源提供
新闻搜索:在网络上搜索新闻
视频搜索:在网络上搜索视频
本地兴趣点搜索:搜索本地实体位置、企业、餐厅、服务等
Related MCP server: Brave Search With Proxy
工具
brave_web_search
使用 Brave 的 API 执行网络搜索
输入:
query(字符串):在互联网上搜索的术语count(数字,可选):返回的结果数(最大 20,默认 10)
brave_image_search
从网络上获取与查询相关的图像
输入:
query(字符串):用于在互联网上搜索图片的术语count(数字,可选):要返回的图像数量(最多 3 个,默认 1 个)
brave_news_search
在网上搜索新闻
输入:
query(字符串):在互联网上搜索新闻文章、热门话题或最近事件的术语count(数字,可选):返回的结果数(最大 20,默认 10)
brave_local_search
搜索本地商家、服务和兴趣点
需要订阅 Pro API 计划才能获取位置结果
如果未找到位置结果,则返回 brave_web_search
输入:
query(字符串):本地搜索词count(数字,可选):返回的结果数(最多 20 个,默认为 5 个)
brave_video_search
在网上搜索视频
输入:
query:(字符串):搜索视频的术语count:(数字,可选):要返回的视频数量(最多 20 个,默认为 10 个)
配置
获取 API 密钥
选择计划(免费套餐,每月 2,000 次查询)
从开发者仪表板生成您的 API 密钥
与 Claude Desktop 一起使用
Docker
克隆 repo
Docker 构建
docker build -t brave-search-mcp:latest -f ./Dockerfile .将其添加到您的
claude_desktop_config.json中:
{
"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
将其添加到您的claude_desktop_config.json中:
{
"mcp-servers": {
"brave-search": {
"command": "npx",
"args": [
"-y",
"brave-search-mcp"
],
"env": {
"BRAVE_API_KEY": "YOUR API KEY HERE"
}
}
}
}与 LibreChat 一起使用
将其添加到 librechat.yaml
brave-search:
command: sh
args:
- -c
- BRAVE_API_KEY=API KEY npx -y brave-search-mcp贡献
欢迎贡献代码!欢迎提交 Pull 请求。
调试
克隆 repo
安装依赖项并构建它
npm install构建应用程序
npm run build使用 VS Code 运行和调试功能
⚠ 似乎在 Windows 10/11 上不起作用,但在 WSL2 中起作用
使用 VS Code Run 和 Debug 启动器,并在代码中设置功能齐全的断点:
找到并选择运行调试。
在下拉菜单中选择标有“
MCP Server Launcher”的配置。选择运行/调试按钮。我们可以使用MCP Inspector和 VS Code 调试各种工具。
VS Code 调试设置
要设置带断点的本地调试:
在 VS Code 中存储 Brave API 密钥
打开命令面板(Cmd/Ctrl + Shift + P)。
类型
Preferences: Open User Settings (JSON)。添加以下代码片段:
{ "brave.search.api.key": "your-api-key-here" }创建或更新
.vscode/launch.json:
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "MCP Server Launcher",
"skipFiles": ["<node_internals>/**"],
"program": "${workspaceFolder}/node_modules/@modelcontextprotocol/inspector/cli/build/cli.js",
"outFiles": ["${workspaceFolder}/dist/**/*.js"],
"env": {
"BRAVE_API_KEY": "${config:brave.search.api.key}",
"DEBUG": "true"
},
"args": ["dist/index.js"],
"sourceMaps": true,
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen",
"preLaunchTask": "npm: build:watch"
},
{
"type": "node",
"request": "attach",
"name": "Attach to Debug Hook Process",
"port": 9332,
"skipFiles": ["<node_internals>/**"],
"sourceMaps": true,
"outFiles": ["${workspaceFolder}/dist/**/*.js"]
},
{
"type": "node",
"request": "attach",
"name": "Attach to REPL Process",
"port": 9333,
"skipFiles": ["<node_internals>/**"],
"sourceMaps": true,
"outFiles": ["${workspaceFolder}/dist/**/*.js"]
}
],
"compounds": [
{
"name": "Attach to MCP Server",
"configurations": ["Attach to Debug Hook Process", "Attach to REPL Process"]
}
]
}创建
.vscode/tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"type": "npm",
"script": "build:watch",
"group": {
"kind": "build",
"isDefault": true
},
"problemMatcher": ["$tsc"]
}
]
}免责声明
此库与 Brave Software 没有正式关联。它是 Brave Search API 与 MCP 服务器的第三方实现。
执照
该项目根据 GNU 通用公共许可证 v3.0 获得许可 - 有关详细信息,请参阅LICENSE文件。
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
MCP server for Firecrawl — web search, scraping, and biomedical/arXiv paper search.
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)
Related MCP Servers
- -licenseNot gradedqualityAmaintenanceAn MCP server implementation that integrates the Brave Search API, providing both web and local search capabilities.31,277 npm91,120MIT
- AlicenseAqualityDmaintenanceAn MCP server for integrating with the Brave Search API, and it supports HTTP proxying.28 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.822,441 npm1,491MIT- AlicenseBqualityDmaintenanceEnables web search capabilities through the Brave Search API, including web search, local POI lookups, and rich search results retrieval for MCP-compatible clients.412 npmMIT