Provides tools for searching the web using the Brave Search API, allowing AI agents to perform web searches.
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 search for top tech news today"
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.
This is a Brave Search MCP HTTP service deployed on Railway.
Fork or upload this directory to a GitHub repository
Log in to the Railway Dashboard
Click New Project → Deploy from GitHub repo
Select the repository you uploaded
Railway will automatically detect package.json and run npm start
Railway will automatically set the PORT environment variable
npm i -g @railway/cli
railway login
railway init
railway upRelated MCP server: Brave Search MCP Server
You must set the following in the Railway Dashboard:
Variable Name | Description | Example |
| Required Brave Search API Key |
|
There is no need to manually set PORT; Railway handles it automatically.
Go to Brave Search API to register
Select the Search plan (suitable for AI Agents)
Generate an API Key in the Developer Dashboard
Railway will provide a domain like https://xxx.up.railway.app.
The MCP endpoint address is: https://xxx.up.railway.app/mcp
Local testing:
curl -s -X POST https://xxx.up.railway.app/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'After deployment, run:
# 添加 MCP 服务器
hermes mcp add brave-search --url https://你的域名.up.railway.app
# 确认无认证需求（API Key 在服务端设置）This allows Hermes to perform searches via the Brave Search MCP service on Railway.
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 |
|---|---|---|---|
| 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 |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| count | No | Number of results (1-200, default 50). Combine this parameter with `offset` to paginate search results. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| items | Yes | |
| count | 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 have openWorldHint=true, with no readOnlyHint or destructiveHint. The description does not disclose any behavioral traits such as side effects, authorization needs, or rate limits, leaving the agent without critical 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?
Three sentences: purpose, examples, and a markdown tip. Well-structured and front-loaded, though the markdown tip is slightly tangential.
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?
With an output schema present and full parameter schema coverage, the description adds appropriate context about image results and markdown usage, though it could mention pagination briefly.
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 provides 100% coverage with descriptions for all 6 parameters. The description adds no additional parameter meaning, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs image searches using Brave API and provides specific use cases (pictures of people, places, etc.), distinguishing it from sibling search tools.
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 ('when you need pictures') and gives concrete examples, though it doesn't mention when not to use or compare directly with siblings.
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 |
|---|---|---|---|
| query | Yes | Search query (max 400 chars, 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 |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| ui_lang | No | The language of the UI. The 2 or more character language code for which the search results are provided. | en-US |
| 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.) | |
| offset | No | Pagination offset (max 9, default 0) | |
| 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 |
| 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. | |
| text_decorations | No | Whether display strings (e.g. result snippets) should include decoration markers (e.g. highlighting characters). | |
| spellcheck | No | Whether to spellcheck the provided query. | |
| result_filter | No | Result filter (default ['web', 'query']) | |
| 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. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). | |
| units | No | The measurement units. If not provided, units are derived from search country. | |
| 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. | |
| summary | No | This parameter enables summary key generation in web search results. This is required for summarizer to be enabled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses plan requirement and auto-fallback behavior. No annotations on safety/destructiveness, but description adds useful context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized: first sentence summarizes, then bullet points for return info. No fluff; each sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description details return fields. Covers plan constraints, fallback, and use cases. Could mention more about parameter interactions but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 15 parameters with descriptions; the tool description adds minimal parameter-specific value beyond listing return fields. Per rules, baseline 3 applies.
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 searches for local businesses/places via Brave Local Search API, lists returned info (names, ratings, hours), and distinguishes from siblings by focusing on location queries.
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 says when to use (location queries, 'near me'), conditions (Pro plan only, else use brave_web_search), and mentions automatic fallback to 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 |
|---|---|---|---|
| query | Yes | Search query (max 400 chars, 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 |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| ui_lang | No | User interface language preferred in response. Usually of the format <language_code>-<country_code>. For more, see RFC 9110. | en-US |
| count | No | Number of results (1-50, default 20) | |
| offset | No | Pagination offset (max 9, default 0) | |
| spellcheck | No | Whether to spellcheck provided query. | |
| 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 |
| 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. | pd |
| 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. | |
| 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. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint=true, indicating external data. The description discloses that results include title, url, description, and optional snippets. It does not cover rate limits, authentication, or error handling, but the core behavior is clear.
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 structured into a purpose statement, 'When to use' list, return format, and examples. It is concise and front-loaded with the primary action.
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?
With 11 parameters and no output schema, the description adequately covers the return value (JSON list with title, url, description). It provides usage context but could detail pagination behavior or filtering nuances.
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?
Input schema has 100% parameter description coverage, so the baseline is 3. The description adds minimal value beyond the schema, but it does mention the query and result format in examples.
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 specifies the verb 'searches' and resource 'news articles', and the title matches. This distinguishes it from siblings like brave_web_search and brave_image_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' list with concrete scenarios like finding recent news, breaking updates, and researching current events. It lacks explicit when-not-to-use or alternatives, but the context of sibling names helps.
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?
With minimal annotations (only title and openWorldHint), the description carries the full burden. It states the tool 'retrieves' summaries, indicating a read-only operation. It mentions optional features and prerequisites. However, it does not discuss error handling or rate limits, but overall behavior is clear.
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 opening sentence, bullet-pointed 'When to use' section, and a final paragraph covering requirements. Every sentence adds value; there is no fluff or repetition. It is appropriately sized for the tool's complexity.
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 three parameters and no output schema, the description covers purpose, prerequisites, optional features, and use cases adequately. It does not detail the output format beyond 'text summary', but that is sufficient for the tool's role as a summarizer.
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 context beyond the schema: it explains that 'key' comes from a prior search result, and describes the optional booleans as enabling inline references and entity info. This adds meaningful guidance.
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 AI-generated summaries via Brave's Summarizer API. It uses a specific verb ('retrieves') and resource ('summaries of web search results'), and distinguishes itself from sibling tools that perform other search types (image, local, news, video, web).
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 when to use (e.g., 'when you need a concise overview') and provides requirements: must first call brave_web_search with summary=true and requires a Pro AI subscription. It also implies when not to use by contrasting with sibling tools.
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 |
|---|---|---|---|
| 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 |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| ui_lang | No | User interface language preferred in response. Usually of the format <language_code>-<country_code>. For more, see RFC 9110. | en-US |
| count | No | Number of results (1-50, default 20). Combine this parameter with `offset` to paginate search results. | |
| offset | No | Pagination offset (max 9, default 0). Combine this parameter with `count` to paginate search results. | |
| spellcheck | No | Whether to spellcheck provided query. | |
| 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 |
| 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only search operation, which aligns with the openWorldHint annotation. However, it does not disclose any potential side effects, authentication needs, or error behaviors beyond what annotations provide. With no destructiveHint or readOnlyHint, a bit more context would be beneficial.
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 with only three sentences plus bullet points. It is front-loaded with purpose and usage, and every sentence adds unique value. No unnecessary repetition.
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 9 parameters and no output schema, the description covers the return format (title, url, etc.) but omits details on pagination or result limitation. Overall it is reasonably complete for a search tool with well-documented schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description only mentions return fields, not adding meaning beyond what the schema provides. The 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 the tool searches for videos using Brave's Video Search API, with a specific verb and resource. It distinguishes from sibling tools like brave_image_search and brave_web_search by 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 'When to use' section provides clear contexts for video searches, such as discovering video content or finding specific creators. It does not explicitly state when not to use or name alternatives, but the context is clear enough for an AI agent.
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 |
|---|---|---|---|
| query | Yes | Search query (max 400 chars, 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 |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| ui_lang | No | The language of the UI. The 2 or more character language code for which the search results are provided. | en-US |
| 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.) | |
| offset | No | Pagination offset (max 9, default 0) | |
| 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 |
| 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. | |
| text_decorations | No | Whether display strings (e.g. result snippets) should include decoration markers (e.g. highlighting characters). | |
| spellcheck | No | Whether to spellcheck the provided query. | |
| result_filter | No | Result filter (default ['web', 'query']) | |
| 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. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). | |
| units | No | The measurement units. If not provided, units are derived from search country. | |
| 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. | |
| summary | No | This parameter enables summary key generation in web search results. This is required for summarizer to be enabled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only have openWorldHint, so description carries burden. It explains that results_filter empty triggers extra result types (FAQ, Discussions, News, Video) beyond the core web results. This adds useful behavioral context beyond what annotations provide.
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?
Description is concise: one sentence for purpose, bullet list for use cases, then return format and special behavior. Every sentence earns its place, no fluff. Front-loaded with the main action.
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 15 parameters and no output schema, the description covers return format (JSON list with title, desc, URL) and a key behavioral nuance (empty results_filter). It could detail more about other result types, but overall is sufficient for a 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 coverage is 100%, so baseline is 3. Description adds that count only affects web results (already in schema) and behavior of results_filter when empty (not in schema). This minor addition justifies maintaining the baseline without penalty.
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 states it performs web searches and returns comprehensive results. It lists specific use cases but includes location-based queries, which are better served by a sibling tool (brave_local_search), potentially confusing the agent. Overall purpose is clear but slightly diluted by broad use cases.
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 a 'When to use' list including general searches, local, news, videos, etc., but does not explicitly compare with sibling tools or state when not to use. It implies context but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct search type (web, image, news, video, local, summarizer) with clear descriptions. No overlapping purposes.
All tools follow 'brave_<type>_search' pattern except 'brave_summarizer', which omits '_search', causing a minor inconsistency.
Six tools cover all major search verticals (web, image, news, video, local, summarizer) without being excessive or insufficient.
The tool set provides a comprehensive search surface for web, images, news, video, local, and summarization, with no obvious gaps for a search-focused MCP server.
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)
Scrape, crawl and search the web for AI agents via MCP.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dodou/brave-search-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
