brave-mcp-server
Provides web search capabilities through the Brave Search API, including filters for freshness, country, language, safe search, result types, and pagination.
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-mcp-serversearch the web for recent developments in fusion energy"
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-mcp-server
Brave Search API 的 MCP 服务器。把 Brave 的
Web Search 端点(GET /res/v1/web/search)暴露成单个 web_search 工具,供
Claude Code 等 MCP 客户端调用。
服务器用 stdio 传输,stdout 只写 JSON-RPC,日志走 stderr。由 npx 按需拉起,
不需要预先安装。
使用
配置
在 MCP 客户端的配置文件里加一条即可。Claude Code 写在 ~/.claude.json 顶层的
mcpServers 里:
{
"mcpServers": {
"brave-search": {
"type": "stdio",
"command": "npx",
"args": ["-y", "brave-mcp-server"],
"env": {
"BRAVE_API_KEY": "你的订阅令牌"
}
}
}
}改完重启客户端生效。
Claude Code 也可以用命令写入同样一段配置:
claude mcp add brave-search --scope user \
-e BRAVE_API_KEY=你的订阅令牌 \
-- npx -y brave-mcp-server环境变量
变量 | 必填 | 说明 |
| 是 | Brave Search 订阅令牌,也可用 |
| 否 | 上游地址,默认 |
缺少 API key 时服务器会打印一行说明并以退出码 1 结束,而不是带着空 key 去请求。
工具:web_search
参数 | 类型 | 说明 |
| string(必填) | 查询词,支持 |
| integer | 返回条数,默认 10,范围 1–20 |
| integer | 翻页偏移,默认 0,范围 0–9(需配合相同的 |
| string |
|
| string | 2 位国家码( |
| string | 语言码。中文只接受 |
| string |
|
| string[] | 只取某类结果: |
| string | 自定义排序规则,可传 GitHub 托管的 goggle 地址或内联规则 |
| boolean | 每条结果额外返回最多 5 段摘录 |
| boolean | 摘要是否保留 |
响应会按 网页结果 / 新闻 / 论坛讨论 / 常见问题 / 视频 / 地点 / 知识卡片
分块渲染成纯文本:HTML 标签和实体被清洗掉,每条结果固定为
「标题 / 链接 / 时效·来源 / 摘要」的缩进格式。
未暴露的上游参数:ui_lang、units、spellcheck、operators、
enable_rich_callback、include_fetch_metadata——对检索结果影响很小,
或需要二次回调,为了让工具签名保持精简而略去。
Related MCP server: Search MCP
开发
代码结构
文件 | 职责 |
| 可执行入口,只负责启动 |
| JSON-RPC 分发与 stdio 生命周期 |
| 工具声明、参数校验与执行 |
| Brave API 客户端与错误整理 |
| 响应渲染成纯文本 |
本地运行
BRAVE_API_KEY=你的令牌 npm start手动跑一轮协议交互(stdin 每行一条 JSON-RPC 消息):
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"web_search","arguments":{"q":"hello"}}}' \
| BRAVE_API_KEY=你的令牌 node bin/brave-mcp-server.js让客户端跑本地源码
把配置里的 args 指向仓库目录即可:
"args": ["-y", "D:/workspace/brave-mcp-server"]注意别在仓库目录里执行这条 npx——npx 会优先解析当前目录的同名包,报
brave-mcp-server 不是内部或外部命令。从别的目录调用,或者直接用
node bin/brave-mcp-server.js。
License
Available Tools
1 toolweb_searchA
使用 Brave Search 检索互联网,返回标题、链接和摘要。适用于查询当前信息、新闻、文档或任何需要联网才能回答的问题。支持按时效(freshness)、地区(country)、语言(search_lang)过滤,用 result_filter 只取某一类结果,用 goggles 自定义排序。查询语法支持 site:、ext:、intitle:、"精确短语"、-排除词 等运算符。
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 搜索查询词。支持 site:example.com、-排除词、"精确短语" 等运算符。 | |
| count | No | 返回结果数量,默认 10,最大 20。实际条数可能少于请求值。 | |
| offset | No | 翻页偏移,默认 0。下一页把 offset 加 1(需配合相同的 count)。 | |
| country | No | 结果来源国家,2 位国家码(如 US、CN、DE)或 ALL,默认 US。 | |
| goggles | No | 自定义排序规则,可传 GitHub 上托管的 goggle 地址,或内联规则(如 "$discard\n$site=docs.python.org")。 | |
| freshness | No | 时效过滤:pd=一天内,pw=一周内,pm=一月内,py=一年内,或 YYYY-MM-DDtoYYYY-MM-DD 自定义区间。 | |
| safesearch | No | 成人内容过滤级别,默认 moderate。 | |
| search_lang | No | 结果语言,语言码如 en、zh-hans、zh-hant、ja。中文必须写 zh-hans(简体)或 zh-hant(繁体),传 zh 会被上游拒绝。 | |
| result_filter | No | 只返回这些类型的结果,默认全部。可选值见 enum,常用来只要 news 或 videos。 | |
| extra_snippets | No | 为每条结果额外返回最多 5 段摘录,默认 false。 | |
| text_decorations | No | 摘要里是否保留 <strong> 高亮标记,默认 false(便于直接阅读)。 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it falls short in some areas. It discloses the return format conceptually (title, link, snippet) and mentions that actual result counts may be less than requested (via schema), but it doesn't clarify key behaviors like rate limits, whether the tool can fail on invalid languages (e.g., 'zh' being rejected is mentioned in the schema not the description), or what happens with offset pagination edge cases. The description does mention filters but doesn't explain the response structure beyond snippets. Given no annotations, a 3 is appropriate for the partial but incomplete behavioral disclosure.
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 dense paragraph that front-loads the core purpose (search internet, return titles/links/snippets) before diving into filters and syntax. Every sentence contributes functionality. However, it reads as a wall of text with no visual breaks; a short list format or cleaner sentence segmentation would improve scanability. Still, it is appropriately sized given the tool's complexity and avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no output schema, and no annotations, the description covers the main functional aspects: what it returns, when to use it, filter categories, and query syntax. It doesn't fully cover edge cases like error behavior or rate limiting, and it doesn't explain what each result type contains, but for a search tool the essentials are present. The parameter schema already provides detailed per-parameter descriptions, offsetting the need for more in the description. A 4 reflects strong coverage with minor omissions.
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, but the description adds meaningful value by grouping parameters into semantic categories: time-based filtering (freshness), regional (country), language (search_lang), result type (result_filter), and custom ordering (goggles). It also introduces the query operator syntax that applies to the q parameter, which enriches the schema's minimal examples. The description doesn't repeat every schema detail but adds conceptual clarity that helps an agent choose parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs internet search via Brave Search and returns titles, links, and snippets, with a specific verb (检索) and resource (互联网/Brave Search). It also enumerates supported filters and query syntax, which distinguishes it from sibling tools, though no siblings are listed. The coverage makes it unambiguous what this tool does.
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 states when to use it: for current information, news, documents, or any question requiring internet access. It also explains filter usage and query operators, giving actionable guidance. However, it doesn't provide explicit when-not-to-use guidance or alternatives, though with no sibling tools listed, this is a minor gap.
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.
1 tool update
v1.0.2- First observed
web_search
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion between overlapping operations. web_search has a clear, single responsibility.
web_search follows a clean snake_case verb_noun format, which is descriptive and conventional. Although there is no other tool to compare against, the naming is consistent with common MCP conventions.
A single tool is minimal, but for a Brave Search server the scope is appropriately narrow and the tool fully represents the server's purpose. It feels slightly thin compared to typical MCP servers, but it is not inappropriate.
The web_search tool exposes the main Brave Search capabilities including general web queries, freshness/country/language filters, result type filtering, and custom ranking. For a search-only server, there are no obvious missing operations.
Related MCP Connectors
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Web MCP: scrape/crawl sites, web search, brand assets, app stores, YouTube, Reddit, Hacker News.
Web search, scraping, RAG answers with citations, and translation as MCP tools.
Related MCP Servers
- FlicenseBqualityDmaintenanceEnables web search and local business data retrieval through the Brave Search API. Provides tools for web search, local points of interest, and rich search results with customizable parameters.4-
- 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
- AlicenseNot gradedqualityDmaintenanceExposes a standardized web search tool via Brave Search for MCP clients like Codex, Claude, and Cursor, returning stable JSON.MIT
- AlicenseNot gradedqualityDmaintenanceEnables web search via Brave Search API with freshness filters, full page content fetching, and usage tracking. Designed for Claude integration.265 npmGPL 3.0