Brave Search MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting different content types: images, local businesses, news articles, videos, and general web content. The descriptions explicitly differentiate use cases (e.g., 'near me' for local search, 'recent events' for news), eliminating any ambiguity between tools.
Naming Consistency5/5
All tool names follow a consistent 'brave_[content_type]_search' pattern, using snake_case uniformly. This predictable naming scheme makes it easy to identify the tool's function and ensures no confusion from mixed conventions.
Tool Count5/5
With 5 tools, this server is well-scoped for its purpose of providing specialized search capabilities across different content types. Each tool earns its place by covering distinct search domains, avoiding both redundancy and excessive fragmentation.
Completeness5/5
The tool set comprehensively covers the search domain by addressing all major content types: images, local information, news, videos, and general web content. There are no obvious gaps, as agents can handle any search query by selecting the appropriate specialized or general tool.
Average 3.8/5 across 5 of 5 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on March 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for 'searching the web for images using the Brave Search API,' which implies a read-only operation but does not clarify aspects like rate limits, authentication needs, or what happens if no results are found. For a tool with zero annotation coverage, this is insufficient, as it lacks details on behavioral traits beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'A tool for searching the web for images using the Brave Search API.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence earns its place by specifying the action, resource, and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects (e.g., rate limits, error handling) and usage guidelines relative to siblings. Without an output schema, it doesn't explain return values, but the schema handles parameters well. This results in a score of 3, indicating it meets the minimum viable threshold but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('searchTerm' and 'count'), including defaults and constraints. The description does not add any semantic details beyond what the schema provides (e.g., it doesn't explain parameter interactions or usage examples). According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'searching the web for images using the Brave Search API.' It specifies the verb ('searching'), resource ('images'), and method ('using the Brave Search API'), which is more informative than just restating the name. However, it does not explicitly distinguish this tool from its sibling tools (e.g., brave_web_search, brave_video_search) beyond implying it's for images, which is why it scores 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (brave_local_search, brave_news_search, brave_video_search, brave_web_search). It mentions 'searching the web for images,' which implies a general image search context, but offers no explicit when/when-not instructions or alternatives. This lack of comparative guidance results in a score of 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: 'Returns a list of articles with titles, URLs, and descriptions' (output format) and 'Maximum 20 results per request' (rate/limit constraint). However, it doesn't mention authentication needs, error handling, pagination, or whether results are cached/fresh. For a search tool with zero annotation coverage, this is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: first sentence states purpose, second gives usage context, third describes output, fourth sets constraints. Every sentence earns its place with no wasted words. It efficiently conveys essential information in four concise sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with parameters), 100% schema coverage, no annotations, and no output schema, the description is reasonably complete. It covers purpose, usage context, output format, and a key constraint. However, without an output schema, it could benefit from more detail on the article structure (e.g., publication date, source) or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (query and count). The description adds no additional parameter semantics beyond what's in the schema. It mentions 'Maximum 20 results per request' which aligns with the schema's count maximum, but doesn't provide new syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Searches for news articles using the Brave Search API' (verb+resource). It distinguishes from siblings by specifying 'news articles' rather than images, local results, videos, or general web content. However, it doesn't explicitly contrast with siblings like 'Use this instead of brave_web_search for news-specific results'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: 'for recent events, trending topics, or specific news stories.' This gives practical guidance. However, it doesn't explicitly state when NOT to use this tool or name alternatives among the sibling tools (e.g., 'Use brave_web_search for general web results instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the maximum results per request (20) and ideal use cases, but doesn't cover other behavioral aspects like rate limits, authentication needs, error handling, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences with zero waste - the first establishes purpose and ideal use cases, the second provides a key behavioral constraint (maximum results). Every element earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description provides adequate purpose and usage guidance but lacks details about response format, error conditions, or authentication requirements that would be helpful for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters (query, count, offset). The description doesn't add any parameter-specific meaning beyond what's in the schema, maintaining the baseline score of 3 for good schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('performs a web search') and resource ('using the Brave Search API'), distinguishing it from siblings like image, local, news, and video search by specifying it's for 'general queries' and 'online content' rather than specialized media types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('broad information gathering, recent events, or when you need diverse web sources'), but it doesn't explicitly state when NOT to use it or name specific alternatives among its siblings (e.g., use brave_news_search for news-specific results).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the return format ('list of videos with titles, URLs, and descriptions') and rate limiting ('Maximum 20 results per request'), but doesn't mention authentication requirements, error handling, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose, usage context, and behavioral constraints. Every sentence adds value with no redundant information, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description provides good coverage of purpose, usage context, and key behavioral constraints. However, it could be more complete by explicitly mentioning the API source (Brave Search) and potential limitations like authentication or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Searches for videos'), resource ('using the Brave Search API'), and distinguishes it from sibling tools by specifying it's for 'video content, tutorials, or any media-related queries' rather than images, local results, news, or web pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('for video content, tutorials, or any media-related queries'), but doesn't explicitly mention when not to use it or name specific alternatives among the sibling tools like 'brave_image_search' or 'brave_web_search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: the fallback mechanism to web search, the types of information returned (business details, ratings, contact info), and the context of local/physical searches. It doesn't mention rate limits, authentication needs, or error handling, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, usage guidelines, and a bulleted list of return details. Every sentence adds value without redundancy, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is quite complete—it covers purpose, usage, behavior, and return details. It lacks output format specifics (e.g., structure of returned data) and error handling, but compensates well with clear operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds minimal parameter semantics beyond the schema—it provides an example query ('pizza near Central Park') that reinforces the schema's guidance but doesn't explain parameter interactions or additional constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Searches for local businesses and places') using a specific resource ('Brave's Local Search API'), and distinguishes it from siblings by specifying it's for 'physical locations, businesses, restaurants, services' rather than images, news, videos, or general web content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when the query implies 'near me' or mentions specific locations') and mentions an alternative behavior ('Automatically falls back to web search if no local results are found'), though it doesn't explicitly name sibling alternatives like 'brave_web_search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 MCP server](https://glama.ai/mcp/servers/mikechao/brave-search-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mikechao/brave-search-mcp)

Score Badge

Copy to your README.md:

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

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/mikechao/brave-search-mcp'

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