Brave Search MCP Server

Official

by brave

Overview Schema Related Servers Score Discussions(1)

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.82
Disambiguation5/5
Each tool has a clearly distinct purpose targeting different search modalities: web, image, local, news, video, and summarization. The descriptions explicitly define when to use each tool, with no overlap in functionality. For example, brave_web_search is for general searches, while brave_news_search is specifically for news articles, and brave_summarizer processes search results into summaries.
Naming Consistency5/5
All tool names follow a consistent 'brave_[type]_search' pattern, with the exception of brave_summarizer which still fits the 'brave_[function]' convention. This uniformity makes it easy to predict tool purposes and maintains readability across the set, adhering to a clear naming scheme throughout.
Tool Count5/5
With 6 tools, this server is well-scoped for a search API, covering key search types (web, image, local, news, video) and an additional summarization feature. Each tool earns its place by addressing a specific use case without redundancy, making the count appropriate and manageable for the domain.
Completeness4/5
The tool set provides comprehensive coverage for search-related tasks, including various result types and a summarization feature. Minor gaps exist, such as no explicit tool for filtering or sorting results, but agents can work around this using parameters in existing tools. The surface effectively supports core search workflows without dead ends.
Average 4.2/5 across 6 of 6 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 13 of 22 community issues answered or closed in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on July 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 433 times in the last 30 days.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the basic function but does not elaborate on behavior beyond search, such as rate limits or data sources. The openWorldHint annotation is consistent, but the description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are direct and front-loaded. First sentence states purpose, second adds a practical usage tip. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and simple tool function, the description is adequately complete. The markdown usage tip adds value, though it could mention result format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the tool description adds no new information about parameters. The baseline of 3 is appropriate as it neither enhances nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs image searches using the Brave Search API and provides examples of use cases. Does not explicitly compare to sibling tools, but the distinction from web, video, and other searches is obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides positive usage cues (e.g., for pictures, art inspiration) but lacks explicit guidance on when not to use it or mention of alternative tools. Relies on sibling context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only openWorldHint=true. The description adds that results are JSON with title, description, URL, and notes behavior when result_filter is empty. However, it does not disclose rate limits, authentication needs, or other side effects, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence, bullet list for usage, return format, and a key note. It is concise yet informative, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, 7 siblings, and no output schema, the description covers purpose, usage, and a key parameter nuance. It could mention pagination limits but offset is in schema. Overall sufficient for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description only adds value by explaining result_filter behavior when empty. Other parameters are well-documented in schema, making the description supplementary but not essential. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Performs web searches using the Brave Search API and returns comprehensive search results with rich metadata,' using specific verbs and resources. It lists multiple use cases, distinguishing from sibling tools like image_search and video_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear 'When to use' list covering various scenarios. However, it lacks explicit 'when not to use' instructions or direct comparisons with sibling tools, though the context of sibling tools implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint: true, so the description adds context by stating it returns a JSON list with title, url, description, and snippets. It also notes some results may contain snippets. While it could mention rate limits or read-only nature, the description sufficiently communicates the tool's behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise purpose statement, bullet-point usage guidelines, return format, and citation examples. Every sentence adds value, and there is no redundancy. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters and no output schema, the description covers the return format and provides usage examples. However, it does not explain pagination or error handling, which are relevant for a search tool. It is fairly complete but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add significant meaning beyond the schema; it only mentions the return format and query usage. No additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for news articles using Brave's News Search API. It distinguishes itself from sibling tools like brave_web_search by specifying 'news articles', and the verb 'search' is specific to the resource. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section gives explicit use cases such as finding recent news, breaking updates, and researching current events. However, it does not provide guidance on when not to use this tool versus alternatives like brave_web_search, leaving some room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only openWorldHint: true, so the description carries the burden. It discloses that the tool returns 'actual substance of matching pages' including text chunks, tables, code blocks, and structured data, and mentions relevance ranking. It does not discuss authentication, rate limits, or potential limitations, but the disclosed behavioral traits are adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, bullet points for usage, and a note about citing sources. It is somewhat lengthy but every sentence adds value, and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (26 parameters) and the presence of an output schema, the description adequately covers purpose, usage, and key behavioral aspects. It does not explain return values (unnecessary due to output schema) but provides sufficient guidance for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context by explaining the role of parameters like 'goggles' as custom re-ranking and the freshness filter formats. This extra context warrants a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves pre-extracted, relevance-ranked web content, optimized for AI agents and RAG. It distinguishes itself from traditional search by emphasizing it returns actual page content (text chunks, tables, etc.) rather than just links, clearly differentiating from sibling tools like brave_web_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists several use cases (grounding answers in web content, RAG, question answering, research) and contrasts with traditional search ('when you need the contents of pages, not just titles...'). However, it does not explicitly state when not to use this tool (e.g., for image or video search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include title and openWorldHint, so description carries full burden. It discloses plan restriction, automatic fallback to web search, and output fields. No contradictions; minor extra context like rate limits could enhance, but current is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with key info upfront: introduction, plan requirement, purpose, output, usage guidance, and fallback. Slightly lengthy but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, input hints, output fields, plan restrictions, and fallback. Without output schema, the description adequately explains what the tool returns. Could mention more about response structure but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% parameter description coverage, so baseline 3 is appropriate. The description adds no additional meaning to parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 and places using Brave's Local Search API, and distinguishes from siblings like brave_web_search by specifying the types of queries (e.g., 'near me', specific locations) and plan requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (location queries) and when not to use (if user lacks Pro plan, use brave_web_search). Provides concrete examples of query types and mentions fallback behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint. Description adds behavioral details: response varies by query shape, radius biases rather than hard-limits, and location format specifics. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for usage and inputs. Every sentence adds value, though it is lengthy; front-loading the main purpose improves clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 17 parameters, no required fields, and an output schema, the description effectively guides parameter selection and explains combinations for different use cases, though it does not detail the output schema (unnecessary as it exists separately).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by explaining when query, latitude/longitude, location, count, and radius are appropriate, and how query shape influences response, going beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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, a specific resource, and lists possible response fields (results, cities, etc.), distinguishing it from sibling search tools that focus on images, news, or general web content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed when-to-use scenarios for different query shapes (POIs, cities, addresses, streets) and explains input requirements (e.g., lat/lon vs location). Lacks explicit exclusions or alternatives among siblings but covers the key decision points.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses optional features (inline_references, entity_info) and requirements (Pro AI subscription, prior web search). The openWorldHint annotation hints at external impact, but the description does not elaborate on side effects; however, the tool is likely read-only for summarization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with bullet points and clear sections. Slightly verbose in the 'When to use' list, but overall efficient and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, optional features, and return type (text summary). Lacks details on output format or example, but the tool is simple enough that the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context beyond the schema: explains that 'key' comes from a previous search result and that entity_info and inline_references are optional enhancements. This helps an agent understand parameter usage in workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves AI-generated summaries from web search results using Brave's Summarizer API. Distinguishes from sibling tools like brave_web_search and brave_llm_context by specifying it processes search results into concise summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use:' bullet points covering overviews, fact-checking, user summaries, and research. Also mentions prerequisites (prior web search with summary=true, Pro AI subscription) but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true, signaling a read-only operation. The description adds value by specifying the return format (JSON list with title, url, description, duration, thumbnail_url), but does not detail other traits like rate limits or authentication. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two efficient sentences and a bullet-list style, front-loading the core purpose and usage. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 9 parameters and full schema coverage, the description adequately covers purpose, usage, and return structure. It does not explain pagination behavior beyond what the schema provides, but that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meeting the baseline of 3. The description goes beyond by listing return fields (duration, thumbnail_url) not in the schema, adding extra semantic value for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 and returns structured results with metadata. It distinguishes itself from sibling tools like brave_web_search and brave_image_search by focusing specifically on video content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section provides clear contexts such as finding videos on a topic, discovering content, getting metadata, or searching by creator. However, it does not explicitly state when not to use it or compare with alternative tools, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![brave-search-mcp-server MCP server](https://glama.ai/mcp/servers/brave/brave-search-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/brave/brave-search-mcp-server)

Score Badge

Copy to your README.md:

[![brave-search-mcp-server MCP server](https://glama.ai/mcp/servers/brave/brave-search-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/brave/brave-search-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/brave/brave-search-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server