When your agent needs web search, 5 MCP servers become an ops risk: how to pick one stack without integration sprawl

I’m Denis Shokhirev, an Agentic AI Systems Architect based in Freiburg im Breisgau, Germany, and at DennisCraft AI Studio I ship production AI systems for DACH B2B clients on Claude, Supabase, n8n, Doppler, and self-hosted Postgres. The operational pain usually starts on the day a team says “we just need web search,” and two sprints later the agent has five MCP servers, three auth patterns, scattered logs, and no clean answer for why latency doubled overnight.

That pattern looks harmless in demos because each tool works on its own. In production, especially in logistics, fintech, and industrial automation, tool sprawl turns into a systems problem: more network hops, more secrets, weaker traceability, and less confidence in what the agent actually saw before it answered.

The problem is not MCP itself. The problem is unchecked MCP multiplication.

I’m not arguing against Model Context Protocol. I’m arguing against treating every new capability as a separate operational island. One server for search, one for crawling, one for browsing, one for internal docs, one for structured data access: now your “agent stack” is really a distributed system with inconsistent controls.

Where the pain shows up first

If an agent sends a customer-facing answer, the postmortem question is never “did we have enough tool endpoints?” It’s “what did the agent query, what came back, what prompt was assembled, what policy allowed it, and what did we store for audit?”

How I pick a stack: optimize for operational surface area, not demo breadth

When I evaluate web search for agents, I use five filters.

1. One authentication model

If search, internal retrieval, and orchestration all use different secret flows, you are already paying an ops tax. I prefer centralized secret management in Doppler and explicit scoping per service.

2. End-to-end traceability for one agent task

A single agent run should carry one correlation ID through n8n, the application backend, Postgres, and the external search path. Without that, incident analysis becomes manual archaeology.

3. Controlled egress

In regulated environments, “the whole web” is not a valid trust boundary. I want domain allowlists, request limits, timeout caps, and a readable access log.

4. Predictable degradation

If web search is down, the agent should degrade into “internal sources only,” not burn retries until the queue backs up.

5. One audit store

I prefer execution metadata, tool calls, and policy decisions in Postgres or Supabase instead of spreading them across five admin dashboards. It is easier to audit and easier to reason about.

The pattern I trust: one tool gateway instead of five direct MCP connections

If an agent needs search, browsing, and retrieval, I usually present one controlled tool interface to the model. Behind that interface, a backend service decides whether to call search, query Postgres, apply policy, normalize results, and persist a trace. To the model, that is one tool. To operations, that is one contract.

import os
import requests
from urllib.parse import urlparse

ALLOWED_HOSTS = {"docs.python.org", "owasp.org"}

def fetch_url(url: str, timeout: int = 8) -> str:
    host = urlparse(url).netloc
    if host not in ALLOWED_HOSTS:
        raise ValueError(f"host not allowed: {host}")

    response = requests.get(
        url,
        timeout=timeout,
        headers={"User-Agent": "agent-gateway/1.0"}
    )
    response.raise_for_status()
    return response.text[:20000]

The key design choice is simple: policy enforcement happens before the outbound call, not after. That lowers risk and makes the architecture easier to explain to customers and auditors.

Why protocol standardization is not enough

Anthropic’s documentation on tool use and Model Context Protocol is useful for standardizing how models access tools, but a protocol does not make authorization, egress policy, or audit design disappear. Source: Anthropic Documentation, 2025, https://docs.anthropic.com/.

The same applies to examples in the OpenAI Cookbook: they are helpful for implementation patterns, but production governance is still your job. Source: OpenAI Cookbook, 2025, https://cookbook.openai.com/.

A minimal production stack for agent web search

For most B2B cases, I do not need a large zoo of integrations. A smaller stack is easier to run well.

export DATABASE_URL="postgresql://app:pass@db/app"
export ANTHROPIC_API_KEY="***"
export SEARCH_TIMEOUT_SECONDS="8"

semgrep --config auto .
bandit -r app/
gitleaks detect --source . --no-banner

python -m app.worker

This matters because integration complexity amplifies ordinary failures. Secrets still leak. Unsafe subprocess calls still happen. SQL still gets assembled badly under deadline pressure. OWASP Top 10 remains a useful anchor for common web application failure modes in systems that are expanding quickly. Source: OWASP Top 10, 2021, https://owasp.org/www-project-top-ten/.

How to tell if you already have integration sprawl

I use a short checklist. If you answer “yes” to three or more, the stack is already drifting out of control:

• Each agent tool has separate credentials and a different operational owner
• You cannot reconstruct one full answer trace in under 10 minutes
• Internet search logs and internal retrieval logs live in different systems
• When search is unavailable, the agent fails instead of degrading cleanly
• No one can quickly list which external domains the agent is allowed to access

If that sounds familiar, do not add a sixth MCP server. Reduce the operational surface first. One gateway, one trace model, one audit store.

FAQ

Is MCP a bad idea?

No. Uncontrolled MCP growth is the bad idea. The protocol is useful when it sits inside a system with clear policy, ownership, and traceability.

When are multiple MCP servers justified?

When you truly have different trust boundaries, isolation needs, or team responsibilities. Even then, you still need a unified audit trail and common observability model.

Can I skip web search entirely?

Often yes, especially if internal retrieval is enough for the job. Web search becomes necessary when the task depends on fast-changing external information.

Why not just buy one all-in-one platform?

That can work for an early phase. In regulated environments, data residency, auditability, and access control usually force a more deliberate architecture.

What matters more first: latency or auditability?

Both matter, but in regulated production systems I secure traceability and control first, then optimize P95.

Which part of your current agent stack causes the most production drag: tracing tool calls, controlling outbound access, or handling degraded mode when external search fails? I’d genuinely like to know.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.