Vetting a search MCP server before your agent depends on it

A web search MCP server is a small piece of software with a large say in what your agent believes. It wraps a search backend, exposes it as one or more tools, and decides what text reaches the model after each call. Choosing one is really two choices. The first is the search backend, which the guide to choosing a web search API covers. The second is the server itself: the tools it declares, the shape of its results, how it authenticates, what happens to your queries, where it runs and what your client lets it do. This page is about the second choice.

What the server adds on top of a search API

The Model Context Protocol lets a client discover tools from a server and call them on the model's behalf. If the terms are new, start with what MCP is. A search server usually does three jobs: it translates a tool call into a request to a search provider or a self-hosted engine, it trims and formats what comes back, and it reports errors.

Each job is a place where two servers built on the same backend can behave very differently. One passes your date filter through; another silently drops it. One returns clean excerpts with dates; another dumps raw page text until the context fills. So test the server, not just the provider behind it. Also find out who maintains it: the search vendor, a framework project or an individual. That tells you how quickly it will follow changes in the underlying API and who answers when it breaks.

Read the tool schema first

Connect the server to a client or an inspector and list its tools before you let a model near it. The model chooses tools from their names and descriptions and fills in arguments from the input schema, so this is the real contract. A reasonable search tool looks something like this:

{
  "name": "web_search",
  "description": "Search the public web. Returns up to max_results items, each with url, title, published date and an excerpt.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "maxLength": 400 },
      "max_results": { "type": "integer", "minimum": 1, "maximum": 10 },
      "include_domains": { "type": "array", "items": { "type": "string" } },
      "recency_days": { "type": "integer", "minimum": 1 }
    },
    "required": ["query"]
  }
}

What to look for:

• Typed, bounded parameters. Integers with limits, fixed choices for region or language, arrays for domain filters. Free-text parameters invite the model to improvise.
• The filters you actually need. Date or recency, domain include and exclude, language. If the backend supports a filter and the schema does not expose it, the agent cannot use it.
• A small tool count. A server that ships search, fetch, crawl and screenshot tools gives the agent more reach and spends more context on tool definitions. Enable what the task needs.
• Plain descriptions. A description that tells the model to prefer this tool over all others, or to call it on every turn, is an instruction hidden in metadata. Treat it as a warning sign.

Result format: what lands in the model's context

Everything the server returns becomes input to the model, so the result format decides both answer quality and cost. Call the tool with a few of your real queries and read the raw output.

Remember that search results are untrusted text written by strangers. A page can contain sentences crafted to steer an agent. A server cannot fully prevent that, but it helps when results are clearly marked as retrieved content and when fetching a page is a separate tool from searching, so you can grant one without the other.

Authentication, secrets and your queries

Most local servers read a backend API key from an environment variable set in the client's configuration file. That file is easy to copy into a repository or a shared dotfiles folder by accident, so keep keys out of anything under version control and use a secret store if your client supports one. Give the agent its own key with its own spending limit on the provider side, so a runaway loop shows up as a capped bill rather than a surprise.

Remote servers typically authenticate the client with OAuth or a token issued by the operator. Check what that token allows beyond search, how it is revoked, and whether it belongs to a person or is shared by a team.

Then follow the queries. An agent's queries are not anonymous keywords: they carry customer names, internal project names, error messages and sometimes snippets of code. Every hop between the client and the search index may log them. Ask the server operator and the backend provider what they keep, for how long, and whether it is used for anything else. For a community server, read the code for telemetry. A self-hosted backend removes one party from that list.

Local or remote

A local server runs as a process on your machine, launched by the client and talking over standard input and output. A remote server is reached over HTTP and run by someone else, or by your own team.

• Local keeps the server's handling of your queries on your machine, but you are executing someone's code with your own user's permissions. Pin a version instead of fetching the latest release on every launch, and review what you install.
• Remote means nothing to install and works from hosted clients, but the operator sees every query and result, and you depend on their uptime and policies.

The trade-offs go deeper than search; the comparison of remote and local MCP servers walks through them.

Permissions in the client

The server declares tools; the client decides what the model may do with them. Search looks harmless because it reads rather than writes, yet it still sends queries outward and brings untrusted text inward. A fetch tool that accepts any URL can also reach addresses on your internal network if the server runs inside it.

Start narrow. Enable the search tool alone, attached to the project that needs it rather than to every workspace you open. Keep approval prompts on for fetch or crawl tools until you have seen how the agent uses them. Read the client's log of tool calls after the first few sessions. The notes on starting agents read-only and on connecting tools without widening authority expand on this habit.

Where GoCux fits

GoCux is not a search MCP server, and it does not offer a hosted MCP endpoint. It also does not read the open web. Its approach to MCP matches the one on this page: tools run inside your own compatible client, you begin with read-only access, and the fact that a server is configured does not mean every task may use it. The MCP quickstart shows the setup.

When web material matters to a piece of work, GoCux brings it in through an explicitly authorized browsing or export step and keeps the original page reference together with the date it was retrieved. A research plan names its sources in an allowlist that is approved before the plan runs, as the source policy explains. A search tool in your client can find candidates; the record of which sources were allowed to answer stays reviewable.

Checklist before you enable a search server

• You know who maintains the server and which backend it calls.
• You listed its tools and read every name, description and parameter.
• The filters you need are exposed and actually reach the backend.
• Results carry URL, title and dates, with a size limit you can live with.
• Errors and empty results come back differently.
• The API key is dedicated, capped and kept out of version control.
• You know who logs your queries and for how long.
• A local server is pinned to a reviewed version; a remote server's token is scoped and revocable.
• Only the search tool is enabled at first, and fetch calls ask before running.