Brave Search MCP Server

The server holds exactly one credential, a Brave Search API key read from the environment, a CLI argument or a key file, and attaches it only to requests to the hard-coded Brave Search API host. That key can only run searches, so a hijacked model can spend quota but cannot reach other systems. There is no per-tool or per-request scoping and no authorization layer; in the optional HTTP mode every client shares the operator's key with no authentication. No subprocesses are spawned, so the key is not passed on.

Every tool is a read-only search against Brave's API; no tool writes files, sends messages or changes state, so a wrongly approved call cannot change anything. However the tools advertise only a title and an 'open world' hint and never declare themselves read-only, so hosts get no machine-readable risk signal and will typically treat them as potentially mutating. There is no server-side read-only mode or confirmation step, but none is needed for the shipped tool set.

Each tool is narrow (a specific Brave Search endpoint) and the destination host is hard-coded, so the model cannot point the server at arbitrary URLs or local services. Inputs are validated with typed schemas: query length and word count limits, enumerated countries and languages, and numeric bounds on result counts and token budgets. The weak spot is the 'goggles' parameter, which accepts any HTTPS URL or free-text definition that Brave's backend then fetches, and a few free-text header fields. All tools are enabled by default, but all are read-only and operators can restrict the list.

The server never executes model-supplied or workspace-supplied text as code: there are no shell, eval, child-process or template-execution paths in the shipped source (the only child_process use is in an HTTP test). This risk surface is structurally absent.

The server's whole job is to pull untrusted web content (search snippets and, via the LLM-context tool, full page text) into the model's context. Results come back as JSON with source URLs, and some tools add structured output, but nothing marks content as untrusted, and the image tool's description actively tells the model to embed remote image URLs in markdown, an automatic-fetch channel that injected content can abuse. The server holds no private data, but a hijacked model can still push data out through model-chosen query text and goggle URLs that Brave's backend fetches. There is no read-only/no-egress mode to drop a Rule-of-Two leg.

The server has no memory or retrieval store, but at startup it silently loads a .env file from its current working directory, which for MCP hosts is often the user's project or a cloned repository. Such a file can swap the operator's API key for one named in a key file, switch the server to HTTP on all interfaces with no authentication, or change the tool list, all without any trust prompt. Process environment variables set by the host still win over .env values, but most of these settings are usually unset.

The server loads no plugins, MCP servers, remote code or model files at runtime; its tool set is fixed at build time. The README's 'npx -y' install line concerns how the server itself is installed (the project's own supply chain), which is out of scope for this criterion.

The API key comes from an environment variable, a key file, or a command-line flag (the last is visible in process listings). It is never placed in tool output or model context and is not logged, and there is no telemetry. But there is no explicit redaction anywhere: upstream error bodies are passed back verbatim, and protection relies on the key simply not being on those paths. The key is long-lived but limited to search.

The server keeps no record of which tools were called, with what arguments, or what was returned. It declares the MCP logging capability but never emits log messages, and the only console output is startup errors and HTTP-mode exceptions. After an incident, the server itself offers nothing to reconstruct what happened; that would have to come from the host or Brave's API dashboard.

Each call's size is bounded by schema limits that the model cannot raise (result counts, query length, LLM-context token budgets), and the summarizer stops polling after 20 attempts. There is no rate limiting (a TODO in the code), no timeout on the outbound HTTP request, and no cancellation of in-flight requests. Spend ceilings depend on the Brave plan's own quota rather than anything the server enforces.