en es ja ko zh

Brave Search MCP

Name: Brave Search MCP
Author: mikechao

by mikechao

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Servidor MCP de Brave Search

Una implementación de servidor MCP que integra la API de Brave Search y proporciona capacidades de búsqueda web, búsqueda de puntos de interés locales, búsqueda de videos, búsqueda de imágenes y búsqueda de noticias.

Características

Búsqueda web : realice una búsqueda regular en la web
Búsqueda de imágenes : Busque imágenes en la web. Los resultados estarán disponibles como recurso.
Búsqueda de noticias : Busque noticias en la web
Búsqueda de videos : busca videos en la web
Búsqueda de puntos de interés locales : busque ubicaciones físicas locales, negocios, restaurantes, servicios, etc.

Related MCP server: Brave Search With Proxy

Herramientas

búsqueda web valiente
- Ejecutar búsquedas web utilizando la API de Brave
- Entradas:
  - query (cadena): El término que se buscará en Internet
  - count (número, opcional): la cantidad de resultados a devolver (máximo 20, valor predeterminado 10)
búsqueda de imágenes valientes
- Obtener imágenes de la web relevantes para la consulta
- Entradas:
  - query (cadena): El término para buscar imágenes de Internet
  - count (número, opcional): la cantidad de imágenes a devolver (máximo 3, predeterminado 1)
búsqueda de noticias valientes
- Busca noticias en la web
- Entradas:
  - query (cadena): El término para buscar en Internet artículos de noticias, temas de tendencia o eventos recientes
  - count (número, opcional): la cantidad de resultados a devolver (máximo 20, valor predeterminado 10)
búsqueda local valiente
- Busque negocios locales, servicios y puntos de interés
- REQUIERE suscripción al plan Pro API para obtener resultados de ubicación
- Vuelve a brave_web_search si no se encuentran resultados de ubicación
- Entradas:
  - query (cadena): término de búsqueda local
  - count (número, opcional): la cantidad de resultados a devolver (máximo 20, predeterminado 5)
búsqueda de videos valientes
- Busca vídeos en la web
- Entradas:
  - query : (cadena): El término para buscar videos
  - count : (número, opcional): la cantidad de videos a devolver (máximo 20, predeterminado 10)

Configuración

Obtener una clave API

Regístrese para obtener una cuenta de Brave Search API
Elija un plan (nivel gratuito disponible con 2000 consultas/mes)
Genere su clave API desde el panel de desarrollador

Uso con Claude Desktop

Estibador

Clonar el repositorio
Compilación de Docker

docker build -t brave-search-mcp:latest -f ./Dockerfile .

Agregue esto a su claude_desktop_config.json :

{
  "mcp-servers": {
    "brave-search": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "BRAVE_API_KEY",
        "brave-search-mcp"
      ],
      "env": {
        "BRAVE_API_KEY": "YOUR API KEY HERE"
      }
    }
  }
}

NPX

Agregue esto a su claude_desktop_config.json :

{
  "mcp-servers": {
    "brave-search": {
      "command": "npx",
      "args": [
        "-y",
        "brave-search-mcp"
      ],
      "env": {
        "BRAVE_API_KEY": "YOUR API KEY HERE"
      }
    }
  }
}

Uso con LibreChat

Añade esto a librechat.yaml

brave-search:
  command: sh
  args:
    - -c
    - BRAVE_API_KEY=API KEY npx -y brave-search-mcp

Contribuyendo

¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.

Depuración

Clonar el repositorio
Instalar dependencias y compilarlo

npm install

Construir la aplicación

npm run build

Utilice la función Ejecutar y depurar de VS Code

⚠ No parece funcionar en Windows 10/11, pero funciona en WSL2

Utilice el iniciador de ejecución y depuración de VS Code con puntos de interrupción completamente funcionales en el código:

Localice y seleccione ejecutar depuración.
Seleccione la configuración denominada " MCP Server Launcher " en el menú desplegable.
Seleccione el botón Ejecutar/Depurar. Podemos depurar las distintas herramientas usando MCP Inspector y VS Code.

Configuración de depuración de VS Code

Para configurar la depuración local con puntos de interrupción:

Almacenar la clave API de Brave en VS Code
- Abra la paleta de comandos (Cmd/Ctrl + Shift + P).
- Preferences: Open User Settings (JSON) .
- Añade el siguiente fragmento:
```
{
  "brave.search.api.key": "your-api-key-here"
}
```
Crear o actualizar .vscode/launch.json :

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "MCP Server Launcher",
      "skipFiles": ["<node_internals>/**"],
      "program": "${workspaceFolder}/node_modules/@modelcontextprotocol/inspector/cli/build/cli.js",
      "outFiles": ["${workspaceFolder}/dist/**/*.js"],
      "env": {
        "BRAVE_API_KEY": "${config:brave.search.api.key}",
        "DEBUG": "true"
      },
      "args": ["dist/index.js"],
      "sourceMaps": true,
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "preLaunchTask": "npm: build:watch"
    },
    {
      "type": "node",
      "request": "attach",
      "name": "Attach to Debug Hook Process",
      "port": 9332,
      "skipFiles": ["<node_internals>/**"],
      "sourceMaps": true,
      "outFiles": ["${workspaceFolder}/dist/**/*.js"]
    },
    {
      "type": "node",
      "request": "attach",
      "name": "Attach to REPL Process",
      "port": 9333,
      "skipFiles": ["<node_internals>/**"],
      "sourceMaps": true,
      "outFiles": ["${workspaceFolder}/dist/**/*.js"]
    }
  ],
  "compounds": [
    {
      "name": "Attach to MCP Server",
      "configurations": ["Attach to Debug Hook Process", "Attach to REPL Process"]
    }
  ]
}

Crear .vscode/tasks.json :

{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "script": "build:watch",
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "problemMatcher": ["$tsc"]
    }
  ]
}

Descargo de responsabilidad

Esta biblioteca no está oficialmente asociada con Brave Software. Es una implementación externa de la API de búsqueda de Brave con un servidor MCP.

Licencia

Este proyecto está licenciado bajo la Licencia Pública General GNU v3.0 - consulte el archivo LICENCIA para obtener más detalles.

Available Tools

5 tools

brave_image_searchB

A tool for searching the web for images using the Brave Search API.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	The number of images to search for, minimum 1, maximum 3
`searchTerm`	Yes	The term to search the internet for images of

TDQS

B3.1/5.0

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.

brave_local_searchA

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' or mentions specific locations. Automatically falls back to web search if no local results are found.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	The number of results to return, minimum 1, maximum 20
`query`	Yes	Local search query (e.g. 'pizza near Central Park')

TDQS

A4.4/5.0

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.

brave_news_searchA

Searches for news articles using the Brave Search API. Use this for recent events, trending topics, or specific news stories. Returns a list of articles with titles, URLs, and descriptions. Maximum 20 results per request.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	The number of results to return, minimum 1, maximum 20
`query`	Yes	The term to search the internet for news articles, trending topics, or recent events

TDQS

A3.8/5.0

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.

brave_video_searchA

Searches for videos using the Brave Search API. Use this for video content, tutorials, or any media-related queries. Returns a list of videos with titles, URLs, and descriptions. Maximum 20 results per request.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	The number of results to return, minimum 1, maximum 20
`query`	Yes	The term to search the internet for videos of

TDQS

A4/5.0

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.

brave_web_searchA

Performs a web search using the Brave Search API, ideal for general queries, and online content. Use this for broad information gathering, recent events, or when you need diverse web sources. Maximum 20 results per request

ParametersJSON Schema

Name	Required	Description
`count`	No	The number of results to return, minimum 1, maximum 20
`offset`	No	The offset for pagination, minimum 0
`query`	Yes	The term to search the internet for

TDQS

A3.9/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.0Apr 22, 2025
- First observedbrave_image_search
- First observedbrave_local_search
- First observedbrave_news_search
- First observedbrave_video_search
- First observedbrave_web_search

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-04-18 10:20 across 5 tools

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.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

brave AOAuth
ai.smithery
Visit https://brave.com/search/api/ for a free API key. Search the web, local businesses, images,…
Search Browser Automation Web Scraping
831,451
Brave Search A
io.github.pipeworx-io
Brave Search MCP — independent web index (no Google/Bing dependency)
Search RAG Systems
5
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
Serper A
io.github.pipeworx-io
Serper MCP — wraps the Serper Google Search API (serper.dev)
Search RAG Systems
2

Related MCP Servers

Brave Search MCP Server
Search Browser Automation
modelcontextprotocol
-
license
Not graded
quality
A
maintenance
An MCP server implementation that integrates the Brave Search API, providing both web and local search capabilities.
Updated 17 days ago (2026-09-03 01:42 UTC)
13,797 npm
90,399
MIT
Brave Search With Proxy
Browser Automation Search Web Scraping
kwp-lab
A
license
A
quality
D
maintenance
An MCP server for integrating with the Brave Search API, and it supports HTTP proxying.
Updated a year ago (2025-05-11 16:40 UTC)
2
18 npm
3
JavaScript
MIT
Brave Search MCP Serverofficial
Research & Data Search Text Summarization
brave
A
license
A
quality
A
maintenance
An MCP implementation that integrates the Brave Search API, providing comprehensive search capabilities including web, local business, image, video, news searches, and AI-powered summarization.
Updated 3 days ago (2026-09-17 17:59 UTC)
8
8
13,040 npm
1,451
MIT
Search MCP
Search Browser Automation
nanameru
A
license
B
quality
D
maintenance
Enables web search capabilities through the Brave Search API, including web search, local POI lookups, and rich search results retrieval for MCP-compatible clients.
Updated a year ago (2025-09-21 14:09 UTC)
4
22 npm
MIT

Servidor MCP de Brave Search

Características

Herramientas

Configuración

Obtener una clave API

Uso con Claude Desktop

Estibador

NPX

Uso con LibreChat

Contribuyendo

Depuración

Utilice la función Ejecutar y depurar de VS Code

Configuración de depuración de VS Code

Descargo de responsabilidad

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Brave Search MCP Serverofficial

Appeared in Searches