Security and Trust Considerations for Search MCP Tools

Granting an agent a live-search tool means feeding it content you don't control — what to think about before you do.

The core risk: prompt injection via search results

The biggest thing to internalize about any live-search tool, MCP or otherwise, is that its output is untrusted content. A search result's title, snippet, or fetched page body is text written by whoever published that page, and it flows straight into the model's context alongside your actual instructions. A malicious or compromised page can contain text specifically crafted to look like an instruction — "ignore previous instructions and do X" — and a model that doesn't clearly distinguish "content I'm reasoning about" from "instructions I should follow" can be manipulated by it. This is the search-tool version of the broader prompt-injection problem, and it gets worse the more autonomous the agent is downstream of the search call.

Scope the tool narrowly

A search MCP server that only returns read-only search results is safer than one bundled with write-capable tools (posting, emailing, purchasing) in the same server or the same agent session, because a successful injection through a search result has less it can actually do. If an agent needs both search and action-taking capabilities, keeping them as clearly separated tools — and ideally requiring explicit confirmation before any action tool fires — limits the blast radius of a bad search result.

Watch what the MCP server itself can see and do

Beyond the search results themselves, consider the MCP server as a piece of software you're trusting: what does it log, where does your API key live, and does it run with any more privilege than it needs? A local, open-source search MCP server you can read the code of is easier to reason about than an opaque hosted one. See building your own search MCP server if you want full visibility into exactly what a server does with a query and a key.

Practical mitigations

Treat everything a search tool returns as data, not instructions, in your system prompt design. Keep result payloads to structured fields (title, snippet, URL) rather than raw fetched HTML where possible, since less freeform text means less surface for injected instructions to hide in. Log queries and results so unusual behavior is traceable after the fact. And apply the same over-broad-scope thinking you'd apply to any tool: a search tool doesn't need write access to anything, and shouldn't be granted it just because it's bundled with other tools in a multi-tool MCP server.