Provides web search and content extraction through the Brave Search API, returning filtered snippets and source links for AI to read, answer, and cite.
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 Jev MCP search for Postgres vs SQLite for a small app, with sources"
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.
English | 简体中文
Web search results often contain junk articles and passages that mention the right keywords without answering the question. This material consumes context and leaves the AI to find answers among unrelated information.
This project removes unhelpful pages and snippets before search results reach the AI, leaving more context for information that can help answer the question.
Built on Brave Search MCP Server, the project uses Brave to search the web and extract content, and Jev to filter it according to the purpose of the search. Retained content keeps its source links and Brave's original ordering so the AI can read, answer, and cite it.
Filtering currently applies only to brave_llm_context. Other search tools remain available, but their results do not pass through this project's filtering layer or call Jev for screening.
Regular web search (brave_web_search) mainly returns links and short summaries that help people decide which pages to open. In contrast, brave_llm_context provides content snippets extracted from web pages for the AI to read directly. In our testing, brave_llm_context delivers significantly higher information density and more material that can directly support an answer. We therefore recommend brave_llm_context even with filtering disabled.
Prepare the following:
A Brave Search API key. A credit card is required. The API provides $5 in free monthly credits, covering 1,000 searches at the current Search plan price.
A Jev API key for filtering.
We recommend setting BRAVE_API_KEY (your Brave key) and TYPESAFE_API_KEY (your Jev key) as environment variables and ensuring that your AI client passes them to the MCP process. The server reads these variables automatically. If your client requires explicit forwarding, use its environment variable settings.
Add the following configuration to your AI client. npx downloads and starts the package automatically:
{
"mcpServers": {
"brave-jev": {
"command": "npx",
"args": [
"-y",
"@romantcig/brave-jev-mcp@latest",
"--transport",
"stdio",
"--enabled-tools",
"brave_llm_context"
]
}
}
}The example uses @latest to get the latest version published on npm.
--enabled-tools selects which tools are exposed to the AI. The configuration above exposes only brave_llm_context. To enable more tools, append their names as separate strings after this argument. If no other tool filtering options are set, removing the argument and its tool names exposes all tools.
Other tools include:
Web search (brave_web_search): mainly returns page links and short summaries, with significantly less detailed content than brave_llm_context.
Local search (brave_local_search): searches for local businesses and places.
News search (brave_news_search): searches recent news articles, supports recency filters, and provides breaking news indicators.
Place search (brave_place_search): searches for businesses, places, addresses, and streets using place names or coordinates.
AI summaries (brave_summarizer): calls the legacy Summarizer API and requires an existing Pro AI plan subscription. Brave has introduced Answers API as its replacement, but this tool has not integrated it.
Video search (brave_video_search).
Image search (brave_image_search).
On first launch, the server creates ~/.brave-jev/config.json with filtering enabled by default. Existing configuration is preserved. The Brave key is required for search. Without a Jev key, search still works, Jev filtering is skipped, and results that would otherwise be filtered include setup instructions.
The MCP server loads its startup arguments, environment variables, filtering configuration, and program version at startup. Restart it for changes to take effect.
Related MCP server: google-search-mcp
Tell the AI what you need to find. For example:
Use Brave MCP's
brave_llm_contextto compare SQLite and PostgreSQL. I am choosing a database for a single-machine application. Focus on deployment complexity, concurrent write limits, and suitable use cases, and include sources.
When choosing a database for a single-machine application, concurrency limits and deployment methods are useful; a generic passage about why choosing a database matters contributes little. With Jev filtering enabled, the AI sends search keywords and search intent separately to the tool. You only need to describe what you need.
To prevent excessive output when the AI omits explicit limits, and to keep sources repeating the same information from filling the context, brave_llm_context uses these defaults:
Parameter | Default | Meaning |
| 10 | Candidate search results considered when selecting context |
| 4000 | Approximate total token budget |
| 800 | Token budget per source |
| 5 | Maximum number of returned sources |
These defaults apply in every filtering mode. Adjust the relevant parameters when calling the tool if you need more sources or detail. count is the number of candidate results, not the number of sources ultimately returned.
Search results first pass through local cleanup rules, then go to Jev for screening against the search intent. If the Jev key is missing or the Jev request fails, the MCP server still returns the content after local cleanup, but Jev's semantic screening is not completed.
Filter configuration guide (Chinese): configuration, operating modes, thresholds, and logging.
Filtering mechanisms (Chinese): three-snippet combination filtering, near-threshold compensation, and inspecting results.
Performs an image search using the Brave Search API. Helpful for when you need pictures of people, places, things, graphic design ideas, art inspiration, and more. When relaying results in a markdown environment, it may be helpful to include images in the results (e.g., ).
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-200, default 50). Image Search is not paginated — raise `count` if you need more results. There is no `offset` parameter. | |
| query | Yes | The user's search query. Query cannot be empty. Limited to 400 characters and 50 words. | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'strict' - Drops all adult content from search results. | strict |
| spellcheck | No | Whether to spellcheck provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| count | Yes | |
| items | Yes | |
| might_be_offensive | Yes | Whether the image might be offensive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (only title and openWorldHint=true), so the description carries most of the behavioral disclosure burden. It discloses the API source (Brave Search API) and a useful result-format characteristic (markdown image embedding). It does not mention rate limits, authentication, error behavior, or what happens with zero results, but the markdown hint adds genuine behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief: three sentences covering purpose, use cases, and a practical markdown tip. The core purpose and use cases are front-loaded, and the markdown hint, while tangential, is actionable and earns its place. There is no redundant or filler text.
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 rich input schema (100% parameter coverage, defaults, constraints) and presence of an output schema, the description is sufficiently complete. It covers what the tool does, when to use it, and adds a practical result-format hint. The main gap is the lack of explicit rate-limit or error behavior context, but the schema and output schema cover most operational needs.
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 six parameters with types, defaults, constraints, and descriptions. The description adds only the markdown URL format hint, which is not a parameter semantic. Baseline 3 is appropriate because the schema carries the parameter documentation burden, and the description neither conflicts with nor meaningfully extends the schema.
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?
Description clearly states a specific verb and resource: 'Performs an image search using the Brave Search API.' The use cases ('pictures of people, places, things, graphic design ideas, art inspiration') help distinguish it from generic search, but it does not explicitly differentiate from sibling tools like brave_video_search or brave_web_search. The purpose is unambiguous, with differentiation implied by the name and 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 gives concrete use cases for when to use image search ('when you need pictures...') and a practical markdown embedding tip. However, it provides no explicit guidance on when not to use this tool or when a sibling like brave_video_search or brave_web_search would be more appropriate. The intended usage context is clear but exclusions/alternatives are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web with Brave and return pre-extracted, relevance-ranked content chunks (prose, tables, code blocks, structured data). Use the returned content directly when it answers the question; fetch the page only when you need the full context or must verify.
For routine calls, omit the four search budget parameters; the server applies the defaults
shown in their descriptions. Increase a budget only when previous results show that more
source coverage or passage detail is needed. `query` supports site:.
Search rules:
- Unfamiliar subject: first search the subject name plus the core question for an overview,
then verify details as needed; do not search for a given detail directly — check whether
it surfaces naturally in the sources.
- Keep only keywords directly relevant to the current question in `query`; do not pack
context and qualifiers into one query.
- Set `freshness` (pd / pw / pm / py) when recency matters; never hardcode a year in `query`.
- Two consecutive searches with heavily overlapping results mean the direction is exhausted:
change the keyword strategy.
- Search serially; go parallel only when confident of each query.
When relaying results, cite the URL returned with each content item.
Source age, when available, is included with that item; it is not a verified publication date.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Candidate search results to consider. Omit to use the default of 10. | |
| query | Yes | Search keywords; supports site:. At most 400 characters and 50 words. | |
| country | No | Two-letter result region code, e.g. "US"; usually omitted. | |
| goggles | No | Re-ranking rules: a Goggle URL, rule text, or an array of them. | |
| freshness | No | Recency filter: pd = 1 day, pw = 7 days, pm = 31 days, py = 365 days, or YYYY-MM-DDtoYYYY-MM-DD. | |
| search_lang | No | Result language code, e.g. "en" or "zh-hans"; usually omitted. | |
| maximum_number_of_urls | No | Returned source budget. Omit to use the default of 5. | |
| maximum_number_of_tokens | No | Approximate total token budget for returned content. Omit to use the default of 4000. | |
| maximum_number_of_tokens_per_url | No | Token budget per source. Omit to use the default of 800. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only declare openWorldHint=true, so the description carries most behavioral disclosure. It explains the return shape (prose, tables, code blocks, structured data), the budget controls, source-age caveats, and that citations should use returned URLs. This is rich context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and output characteristics, then moves to usage guidance and search rules. It is longer than average, but the length is largely justified by the tool's complexity and the absence of an output schema. Formatting is a bit dense, but sentences generally earn their place.
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 complex search tool with nine parameters, no output schema, and only an openWorldHint annotation, the description is complete enough. It explains what is returned, how to use the results, how budgets behave, and cites URL/source-age caveats. An agent has the context needed to call and interpret this tool correctly.
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 useful semantics by telling the agent to omit the four budget parameters for routine calls, that defaults are applied server-side, and to increase budgets only when more coverage or detail is needed. It also notes that query supports site:, though it does not add meaning for every parameter beyond the schema.
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 a specific verb and resource: searches the web with Brave and returns pre-extracted, relevance-ranked content chunks. It also distinguishes the output from a normal web result set by naming the content types and explaining when to fetch the full page instead. This lets an agent differentiate it from sibling search tools without opening the schema.
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?
It gives strong when-to-use guidance: use returned chunks directly when sufficient, fetch the page only for full context or verification, omit budget parameters for routine calls, and increase budgets only when more coverage is needed. It also provides detailed search strategy rules. However, it does not explicitly name or compare against sibling alternatives such as brave_web_search or brave_news_search, so it falls short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brave Local Search API provides enrichments for location search results. Access to this API is available only through the Brave Search API Pro plans; confirm the user's plan before using this tool (if the user does not have a Pro plan, use the brave_web_search tool). Searches for local businesses and places using Brave's Local Search API. Best for queries related to physical locations, businesses, restaurants, services, etc.
Returns detailed information including:
- Business names and addresses
- Ratings and review counts
- Phone numbers and opening hours
Use this when the query implies 'near me', 'in my area', or mentions specific locations (e.g., 'in San Francisco'). This tool automatically falls back to brave_web_search if no local results are found.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-20, default 10). Applies only to web search results (i.e., has no effect on locations, news, videos, etc.) | |
| query | Yes | Search query (max 400 chars, 50 words) | |
| units | No | The measurement units. If not provided, units are derived from search country. | |
| offset | No | Pagination offset (max 9, default 0) | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| goggles | No | Goggles act as a custom re-ranking on top of Brave's search index. The parameter supports both a url where the Goggle is hosted or the definition of the Goggle. Multiple goggle URLs and/or definitions can be provided in an array. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). | |
| summary | No | This parameter enables summary key generation in web search results. This is required for summarizer to be enabled. | |
| ui_lang | No | The language of the UI. The 2 or more character language code for which the search results are provided. | en-US |
| freshness | No | Filters search results by when they were discovered. The following values are supported: 'pd' - Discovered within the last 24 hours. 'pw' - Discovered within the last 7 days. 'pm' - Discovered within the last 31 days. 'py' - Discovered within the last 365 days. 'YYYY-MM-DDtoYYYY-MM-DD' - Timeframe is also supported by specifying the date range e.g. 2022-04-01to2022-07-30. | |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'moderate' - Filters explicit content (e.g., images and videos), but allows adult domains in search results. 'strict' - Drops all adult content from search results. The default value is 'moderate'. | moderate |
| spellcheck | No | Whether to spellcheck the provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| result_filter | No | Result filter (default ['web', 'query']) | |
| extra_snippets | No | A snippet is an excerpt from a page you get as a result of the query, and extra_snippets allow you to get up to 5 additional, alternative excerpts. Only available under Free AI, Base AI, Pro AI, Base Data, Pro Data and Custom plans. | |
| text_decorations | No | Whether display strings (e.g. result snippets) should include decoration markers (e.g. highlighting characters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are limited (no hints visible in the prompt), but the description discloses key behaviors: it automatically falls back to brave_web_search if no local results are found, it returns business names/addresses/ratings/hours (though this is result content), and it notes the Pro plan requirement. This goes beyond what annotations would provide, though the description does not mention whether it makes network calls or any rate limits. Given no annotations, this is strong.
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 moderately concise, with useful details packed in. The key use case and fallback are front-loadedaving some redundancy (e.g., 'location search results' near the start). It is structured well with bullets for return info. Slight verbosity but efficient.
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 10 parameters in the schema with descriptions, the description adds context about return types (business names, addresses, ratings, hours) and fallback behavior sematically. It does not mention output format, but the schema covers parameter constraints. It also explains the plan requirement. Overall complete for an API tool description.
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 schema is rich with descriptions for every parameter (count, units, country, etc.), so coverage is high. The description adds usage context (e.g., 'Use this when...') and the fallback behavior, which is not in the schema. It also explains the output fields (business names, addresses, ratings, phone, hours) that are not in the schema. Slight deduction because it doesn't clarify how parameters like 'summary' or 'freshness' apply specifically to local results, but overall adds meaning.
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 local businesses and places using Brave's Local Search API (spelled out in the opening). It distinguishes itself from brave_web_search by stating it is for physical locations, businesses, restaurants, services, and specifies it falls back to brave_web_search. The verb 'search' and resource 'local businesses and places' is specific.
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?
Provides explicit when-to-use guidance: 'when the query implies physical locations, businesses, restaurants, services, etc.' Also gives example triggers ('in my area', specific locations). It notes access restriction (Pro plan only) and tells the agent to check the user's plan, with a fallback to brave_web_search. This is excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool searches for news articles using Brave's News Search API based on the user's query. Use it when you need current news information, breaking news updates, or articles about specific topics, events, or entities.
When to use:
- Finding recent news articles on specific topics
- Getting breaking news updates
- Researching current events or trending stories
- Gathering news sources and headlines for analysis
Returns a JSON list of news-related results with title, url, and description. Some results may contain snippets of text from the article.
When relaying results in markdown-supporting environments, always cite sources with hyperlinks.
Examples:
- "According to [Reuters](https://www.reuters.com/technology/china-bans/), China bans uncertified and recalled power banks on planes".
- "The [New York Times](https://www.nytimes.com/2025/06/27/us/technology/ev-sales.html) reports that Tesla's EV sales have increased by 20%".
- "According to [BBC News](https://www.bbc.com/news/world-europe-65910000), the UK government has announced a new policy to support renewable energy".| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-50, default 20) | |
| query | Yes | Search query (max 400 chars, 50 words) | |
| offset | No | Pagination offset (max 9, default 0) | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| goggles | No | Goggles act as a custom re-ranking on top of Brave's search index. The parameter supports both a url where the Goggle is hosted or the definition of the Goggle. Multiple goggle URLs and/or definitions can be provided in an array. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). | |
| ui_lang | No | User interface language preferred in response. Usually of the format <language_code>-<country_code>. For more, see RFC 9110. | en-US |
| freshness | No | Filters search results by when they were discovered. The following values are supported: 'pd' - Discovered within the last 24 hours. 'pw' - Discovered within the last 7 Days. 'pm' - Discovered within the last 31 Days. 'py' - Discovered within the last 365 Days. 'YYYY-MM-DDtoYYYY-MM-DD' - Timeframe is also supported by specifying the date range e.g. 2022-04-01to2022-07-30. | |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'moderate' - Filter out explicit content. 'strict' - Filter out explicit and suggestive content. The default value is 'moderate'. | moderate |
| spellcheck | No | Whether to spellcheck provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| extra_snippets | No | A snippet is an excerpt from a page you get as a result of the query, and extra_snippets allow you to get up to 5 additional, alternative excerpts. Only available under Free AI, Base AI, Pro AI, Base Data, Pro Data and Custom plans. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no readOnly or destructive annotations, the description carries the behavioral burden. It explicitly states the return format ('JSON list of news-related results with title, url, and description') and notes that some results may contain snippets. It also adds citation instructions for markdown environments. It does not cover error handling or rate limits, but the read-only nature of a search is implicit.
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 and front-loaded, starting with the core purpose and followed by usage contexts, return format, and examples. The three citation examples are somewhat repetitive but reinforce a key behavior. Overall, it is appropriately sized with minimal waste.
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?
Though the tool has 11 parameters, the schema fully documents them, and the description fills the gap left by the missing output schema by describing the JSON response and citation expectations. For a search tool with no side effects and clear sibling differentiation, the definition covers everything an agent needs to invoke it correctly.
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?
All parameters have descriptions in the input schema, giving 100% schema description coverage. The tool description does not add parameter-specific details beyond the schema, so 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 opens with a specific verb and resource: 'searches for news articles using Brave's News Search API.' It clearly distinguishes this from sibling tools like brave_web_search by emphasizing news-specific use cases such as breaking news and current events. The scope is unambiguous and immediately actionable.
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 lists concrete scenarios: finding recent news articles, getting breaking updates, researching current events, and gathering sources. However, it does not explicitly state when not to use this tool or name alternative sibling tools, so it provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches Brave's Place Search API. A single call may populate any combination of 'results' (POIs), 'cities', 'addresses', 'streets', and 'location' (the resolved search area), depending on the query's shape.
When to use:
- POIs near coordinates or a named area (e.g. "coffee shops in Paris") -> 'results', each with structured business data (postal address, hours, contact, ratings, photos, categories, timezone).
- Browsing general POIs (omit 'query'; supply 'latitude'+'longitude' or 'location').
- Disambiguating a bare city name (e.g. "springfield") -> 'cities'.
- Resolving a specific address (e.g. "350 5th avenue" with NYC coords) -> 'addresses' (often plus 'streets').
- Looking up a street by name (e.g. "michigan avenue" with Chicago coords) -> 'streets'.
Inputs:
- Anchor the search via 'latitude'+'longitude' or 'location' (or both). With neither, 'query' is required.
- 'addresses' / 'streets' only surface when the query is address-/street-shaped AND geographically anchored.
- 'location' format: US -- '<city> <state> <country>' (e.g. 'san francisco ca united states'); non-US -- '<city> <country>' (e.g. 'tokyo japan'). Capitalization and commas don't matter.
- 'count' caps results (max 50, default 20). 'radius' (meters) biases toward closer results; it does NOT hard-limit the search area.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results to return. Maximum is 50. Default is 20. | |
| query | No | Query string. Shape influences the response: POI-like queries -> `results`; bare/ambiguous city names -> `cities`; address- or street-shaped queries with a geographic anchor -> `addresses` and/or `streets`. If omitted, returns general POIs in the supplied area. | |
| units | No | Units of measurement for distance values. Defaults to 'metric'. | |
| accept | No | The default supported media type is application/json. | |
| geoloc | No | Optional geolocation token used to refine results. | |
| radius | No | Bias toward results closer to the supplied coordinates, in meters. NOT a hard cutoff -- the API may still return more distant results. If omitted, the search is performed globally. | |
| country | No | Two-letter country code (ISO 3166-1 alpha-2) used to scope the search. Defaults to 'US'. | |
| ui_lang | No | User interface language for the response, usually of the form '<language>-<region>'. Defaults to 'en-US'. | |
| latitude | No | Latitude of the geographical coordinates around which to search, in degrees (-90 to 90). Typically paired with `longitude`. | |
| location | No | Location string to search around, used as an alternative to `latitude` and `longitude`. For US locations prefer the form '<city> <state> <country name>' (e.g. 'san francisco ca united states'); for non-US locations use '<city> <country name>' (e.g. 'tokyo japan'). No commas or special characters needed; capitalization does not matter. | |
| longitude | No | Longitude of the geographical coordinates around which to search, in degrees (-180 to 180). Typically paired with `latitude`. | |
| safesearch | No | Safe search level for the query results. 'off' - No filtering. 'moderate' - Filter out explicit content. 'strict' - Filter out explicit and suggestive content. Defaults to 'strict'. | |
| spellcheck | No | Whether to apply spellcheck before executing the search. Defaults to true. | |
| user-agent | No | The user agent originating the request. Brave Search can utilize the user agent to provide a different experience depending on the device as described by the string. The user agent should follow the commonly used browser agent strings on each platform. For more information on curating user agents, see RFC 9110. | |
| api-version | No | The API version to use. This is denoted by the format YYYY-MM-DD. Default is the latest that is available. Read more about API versioning at https://api-dashboard.search.brave.com/documentation/guides/versioning. | |
| search_lang | No | Language for the search results. Defaults to 'en'. | |
| cache-control | No | Brave Search will return cached content by default. To prevent caching set the Cache-Control header to no-cache. This is currently done as best effort. |
| Name | Required | Description |
|---|---|---|
| type | Yes | Top-level response discriminator. Always "locations" for Place Search. |
| query | No | |
| cities | No | City matches for the query. Typically populated when the query is a bare or ambiguous city name (e.g. "springfield", "san francisco"). |
| results | No | Points of interest matching the search. Populated for POI-shaped queries. |
| streets | No | Street matches. Typically populated when the query is a street name AND is geographically anchored via `latitude`+`longitude` or a specific `location`. |
| location | No | The search area as resolved by the API (e.g. coordinates + city name). Useful for confirming the API interpreted the input as expected and for grounding follow-up queries. |
| addresses | No | Address matches. Typically populated when the query is a street + number AND is geographically anchored via `latitude`+`longitude` or a specific `location`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that a single call may populate any combination of fields based on query shape, that 'radius' is a bias rather than a hard limit, and that 'count' caps results. It also details 'location' format requirements. These behaviors extend well beyond the openWorldHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear headings and bullet points, leading with purpose before details. It is dense with information but not redundant; every sentence contributes to selection or invocation understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all key usage scenarios, parameter interdependencies, and edge cases (e.g., radius not hard-limiting, location format). Given the output schema and full schema coverage, it omits only what is already structured, making it complete for an agent to call correctly.
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?
Even with 100% schema coverage, the description adds significant meaning: it maps query shapes to response types, requires geographic anchors for address/street queries, clarifies 'location' formatting, and explains radius/count behavior. This goes far beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Searches Brave's Place Search API' and enumerates the response categories (results, cities, addresses, streets, location). The title and content unambiguously differentiate it from sibling search tools by focusing on places and geographic data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated 'When to use' section lists five distinct scenarios with concrete examples (POIs near coordinates, general browsing, city disambiguation, address resolution, street lookup). It also explains anchor requirements and query prerequisites, giving agents explicit decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves AI-generated summaries of web search results using Brave's Summarizer API. This tool processes search results to create concise, coherent summaries of information gathered from multiple sources.
When to use:
- When you need a concise overview of complex topics from multiple sources
- For quick fact-checking or getting key points without reading full articles
- When providing users with summarized information that synthesizes various perspectives
- For research tasks requiring distilled information from web searches
Returns a text summary that consolidates information from the search results. Optional features include inline references to source URLs and additional entity information.
Requirements: Must first perform a web search using brave_web_search with summary=true parameter. Requires a Pro AI subscription to access the summarizer functionality.| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key is equal to value of field key as part of the Summarizer response model. | |
| entity_info | No | Returns extra entities info with the summary response. | |
| inline_references | No | Adds inline references to the summary response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint=true, offering no read/destructive hints. The description carries the burden and does so well: it says 'Retrieves' and 'Returns a text summary,' clearly implying a non-mutating read operation. It also discloses the subscription requirement. While it doesn't discuss error handling or rate limits, for a read-only summarizer the key behavioral traits are covered.
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 statement, a bulleted 'When to use' section, return details, and requirements. Each section is concise and front-loaded with the core purpose. No redundant sentences; every part earns its place.
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 3 parameters, no output schema, and only openWorldHint annotation, the description covers the return type ('text summary'), prerequisite workflow, and optional features. It does not explain potential errors or the exact format of the key beyond referencing the response model, but for a tool of this simplicity it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by linking the optional boolean parameters to their features ('inline references to source URLs' and 'additional entity information'). It also explains the source of the required 'key' by referencing the prior web search with summary=true, which is crucial for parameter usage. This goes beyond the schema's minimal description.
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 a specific verb ('Retrieves AI-generated summaries'), a clear resource (web search results via Brave's Summarizer API), and explicitly differentiates from sibling search tools by focusing on summarization rather than search. It is immediately obvious what the 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 provides an explicit 'When to use' list with concrete scenarios (overviews, fact-checking, synthesis). It also states a hard prerequisite: 'Must first perform a web search using brave_web_search with summary=true parameter,' which effectively tells the agent the required precondition and the sibling tool to use. This is clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for videos using Brave's Video Search API and returns structured video results with metadata.
When to use:
- When you need to find videos related to a specific topic, keyword, or query.
- Useful for discovering video content, getting video metadata, or finding videos from specific creators/publishers.
Returns a JSON list of video-related results with title, url, description, duration, and thumbnail_url.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-50, default 20). Combine this parameter with `offset` to paginate search results. | |
| query | Yes | The user's search query. Query cannot be empty. Limited to 400 characters and 50 words. | |
| offset | No | Pagination offset (max 9, default 0). Combine this parameter with `count` to paginate search results. | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| ui_lang | No | User interface language preferred in response. Usually of the format <language_code>-<country_code>. For more, see RFC 9110. | en-US |
| freshness | No | Filters search results by when they were discovered. The following values are supported: 'pd' - Discovered within the last 24 hours. 'pw' - Discovered within the last 7 days. 'pm' - Discovered within the last 31 days. 'py' - Discovered within the last 365 days. 'YYYY-MM-DDtoYYYY-MM-DD' - timeframe is also supported by specifying the date range (e.g. '2022-04-01to2022-07-30'). | |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'moderate' - Filter out explicit content. 'strict' - Filter out explicit and suggestive content. The default value is 'moderate'. | moderate |
| spellcheck | No | Whether to spellcheck provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide only openWorldHint=true, which is minimal. The description mentions it 'returns structured video results with metadata' and lists the return fields, but doesn't disclose potential behaviors like pagination limits (offset max 9 is in schema, not description), rate limits, or any error conditions. For a read-only search tool, the safety profile is implied but not explicitly stated. This is adequate but could be richer.
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 efficient: a one-sentence function summary, a 'When to use' bullet list, and a one-line return format summary. It is front-loaded with the core purpose and key use cases. Each bullet adds value without redundancy. Slightly more than necessary but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters but only 1 required (query). The schema provides exhaustive descriptions for every parameter, and the description covers the purpose and return format. Since there is no output schema, the description's note about 'JSON list of video-related results with title, url, description, duration, and thumbnail_url' compensates for missing output schema. Combined complexity is high, but the description plus schema cover everything an agent needs to call it correctly. Missing: explicit statement that it's read-only, but openWorldHint=true implies it's a safe world state. Overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters are already documented in the schema. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is correct since the schema does the heavy lifting; no extra value from the description.
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 a specific verb ('Searches for videos'), the resource ('Brave's Video Search API'), and clearly differentiates from siblings by mentioning video-specific output fields (title, url, duration, thumbnail_url). It is immediately clear this is distinct from web, image, news, and local 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 includes a 'When to use' section that lists concrete conditions: 'need to find videos related to a specific topic... discovering video content, getting video metadata, or finding videos from specific creators/publishers'. It doesn't explicitly state when NOT to use it or name alternatives, but the context is clear and sufficient for an agent to select it appropriately among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs web searches using the Brave Search API and returns comprehensive search results with rich metadata.
When to use:
- General web searches for information, facts, or current topics
- Location-based queries (restaurants, businesses, points of interest)
- News searches for recent events or breaking stories
- Finding videos, discussions, or FAQ content
- Research requiring diverse result types (web pages, images, reviews, etc.)
Returns a JSON list of web results with title, description, and URL.
When the "results_filter" parameter is empty, JSON results may also contain FAQ, Discussions, News, and Video results.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-20, default 10). Applies only to web search results (i.e., has no effect on locations, news, videos, etc.) | |
| query | Yes | Search query (max 400 chars, 50 words) | |
| units | No | The measurement units. If not provided, units are derived from search country. | |
| offset | No | Pagination offset (max 9, default 0) | |
| country | No | Search query country, where the results come from. The country string is limited to 2 character country codes of supported countries. | US |
| goggles | No | Goggles act as a custom re-ranking on top of Brave's search index. The parameter supports both a url where the Goggle is hosted or the definition of the Goggle. Multiple goggle URLs and/or definitions can be provided in an array. For more details, refer to the Goggles repository (i.e., https://github.com/brave/goggles-quickstart). | |
| summary | No | This parameter enables summary key generation in web search results. This is required for summarizer to be enabled. | |
| ui_lang | No | The language of the UI. The 2 or more character language code for which the search results are provided. | en-US |
| freshness | No | Filters search results by when they were discovered. The following values are supported: 'pd' - Discovered within the last 24 hours. 'pw' - Discovered within the last 7 days. 'pm' - Discovered within the last 31 days. 'py' - Discovered within the last 365 days. 'YYYY-MM-DDtoYYYY-MM-DD' - Timeframe is also supported by specifying the date range e.g. 2022-04-01to2022-07-30. | |
| safesearch | No | Filters search results for adult content. The following values are supported: 'off' - No filtering. 'moderate' - Filters explicit content (e.g., images and videos), but allows adult domains in search results. 'strict' - Drops all adult content from search results. The default value is 'moderate'. | moderate |
| spellcheck | No | Whether to spellcheck the provided query. | |
| search_lang | No | Search language preference. The 2 or more character language code for which the search results are provided. | en |
| result_filter | No | Result filter (default ['web', 'query']) | |
| extra_snippets | No | A snippet is an excerpt from a page you get as a result of the query, and extra_snippets allow you to get up to 5 additional, alternative excerpts. Only available under Free AI, Base AI, Pro AI, Base Data, Pro Data and Custom plans. | |
| text_decorations | No | Whether display strings (e.g. result snippets) should include decoration markers (e.g. highlighting characters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the action of performing a search. It does not mention whether the operation is read-only, any rate limits, authentication requirements, or side effects, which is a significant gap given the lack of readOnlyHint or destructiveHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear opening statement, a bulleted list of use cases, and a note about results_filter. The structure is well-organized and easy to scan without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a high-level overview of the return value ('comprehensive search results with rich metadata') and includes usage scenarios. While it does not detail the output structure (no output schema exists), it provides enough context to understand the tool's function and key behaviors.
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 schema provides thorough descriptions for all parameters (100% coverage), and the description adds extra context, such as the behavior of result_filter when empty and how it affects returned result types. This goes beyond the schema's generic description.
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: performing web searches via the Brave Search API and returning comprehensive results. It distinguishes itself from sibling search tools by explicitly mentioning 'web searches' and the general nature of the 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 lists several concrete scenarios, such as general web searches, location-based queries, and news searches. However, it does not explicitly contrast with sibling tools (e.g., when to use local search instead), leaving some ambiguity about edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2brave_image_searchbrave_llm_contextbrave_local_searchbrave_news_searchbrave_place_searchbrave_summarizerbrave_video_searchbrave_web_searchScored across 8 tools
Each tool targets a distinct search modality or output format (web, images, video, news, summaries, LLM context), so broad intent is usually clear. The main overlap is between brave_local_search and brave_place_search, which both return business/POI data; descriptions differentiate use cases but an agent could still misselect.
All tools use a consistent brave_ prefix and snake_case, with six following a brave_<type>_search pattern. The two exceptions (brave_summarizer, brave_llm_context) are still clearly named and predictable.
Eight tools map cleanly to Brave Search API endpoints, with no redundant or filler entries. The count is well-scoped for a search provider.
The surface covers all major Brave Search API capabilities: web, local, video, image, news, summarizer, LLM context, and place search. No obvious gap in the core search lifecycle.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Real-time web search for AI agents: ranked results, source URLs, and optional AI answers.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
