Skip to main content
Glama
arben-adm

Brave Search MCP Server

brave_web_search

Perform web searches using Brave Search API to retrieve relevant results for queries, with configurable result count options.

Instructions

Execute web search using Brave Search API with improved results

        Args:
            query: Search terms
            count: Desired number of results (10-20)
        

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
countNo

Implementation Reference

  • The handler function for 'brave_web_search' tool, including the MCP registration decorator. It performs a web search using the Brave API, formats up to 20 results with title, description, URL, and extra snippets.
    @self.mcp.tool()
    async def brave_web_search(
        query: str,
        count: Optional[int] = 20
    ) -> str:
        """Execute web search using Brave Search API with improved results
        
        Args:
            query: Search terms
            count: Desired number of results (10-20)
        """
        min_results = max(10, min(count, 20))  # Ensure between 10 and 20
        
        all_results = await self._get_web_results(query, min_results)
        
        if not all_results:
            return "No results found for the query."
            
        formatted_results = []
        for result in all_results[:min_results]:
            formatted_result = [
                f"Title: {result.get('title', 'N/A')}",
                f"Description: {result.get('description', 'N/A')}",
                f"URL: {result.get('url', 'N/A')}"
            ]
            
            # Include additional context if available
            if result.get('extra_snippets'):
                formatted_result.append("Additional Context:")
                formatted_result.extend([f"- {snippet}" for snippet in result['extra_snippets'][:2]])
                
            formatted_results.append("\n".join(formatted_result))
        
        return "\n\n".join(formatted_results)
  • Supporting helper method that makes the actual HTTP request to Brave's web/search API, handles rate limiting, and falls back on error 422 by reducing count.
    async def _get_web_results(self, query: str, min_results: int) -> List[Dict]:
        """Fetch web results with pagination until minimum count is reached"""
        client = self.get_client()
        self.rate_limit.check()
        
        try:
            # Make a single request with the maximum allowed count
            response = await client.get(
                f"{self.base_url}/web/search",
                params={
                    "q": query,
                    "count": min_results
                }
            )
            response.raise_for_status()
            data = response.json()
            results = data.get("web", {}).get("results", [])
            return results
        except httpx.HTTPStatusError as e:
            if e.response.status_code == 422:
                # If we get a 422, try with a smaller count
                response = await client.get(
                    f"{self.base_url}/web/search",
                    params={
                        "q": query,
                        "count": 10  # Fall back to smaller count
                    }
                )
                response.raise_for_status()
                data = response.json()
                return data.get("web", {}).get("results", [])
            raise  # Re-raise other HTTP errors
  • src/server.py:57-57 (registration)
    Calls _setup_tools() in __init__ which defines and registers the tools including brave_web_search.
    self._setup_tools()
  • Input schema defined by type hints and docstring in the handler function.
        query: str,
        count: Optional[int] = 20
    ) -> str:
        """Execute web search using Brave Search API with improved results
        
        Args:
            query: Search terms
            count: Desired number of results (10-20)
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 mentions 'improved results' but doesn't explain what this means (e.g., better ranking, additional metadata). It lacks details on rate limits, authentication needs, error handling, or what the output looks like (e.g., format of search results). For a tool with no annotation coverage, this is a significant gap in transparency.

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 appropriately sized and front-loaded, starting with the core purpose. The two-sentence structure is efficient, with the second sentence dedicated to parameter details. There's minimal waste, though the formatting with indentation and quotes might slightly affect readability in some contexts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a web search tool with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return values (e.g., what 'improved results' include), error conditions, or usage constraints. For a tool that interacts with an external API, more context is needed to ensure reliable agent invocation.

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 0%, so the description must compensate. It adds basic semantics for both parameters: 'query' as 'Search terms' and 'count' as 'Desired number of results (10-20)'. This clarifies the purpose of each parameter beyond the schema's titles ('Query' and 'Count'). However, it doesn't provide deeper context like query syntax examples or why count has a range, leaving room for improvement.

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: 'Execute web search using Brave Search API with improved results.' It specifies the verb ('Execute web search') and resource ('Brave Search API'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from its sibling 'brave_local_search' (e.g., by mentioning this is for general web searches vs. local searches), which prevents a perfect score.

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 alternatives. It doesn't mention the sibling tool 'brave_local_search' or any other potential alternatives, nor does it specify contexts or prerequisites for usage. The only implied usage is for web searches, but this is too vague for effective tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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

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