Skip to content

← Back to projects

LOUST

louzt/serpapi-mcp

Period: Jan 2026 —

Active

The challenge

Agentic loops need fresh web evidence to verify claims. Baking a specific search API into the agent creates lock-in; building my own bridge from scratch costs engineering time I would rather spend on the agent itself.

My role

I built a Go-based MCP server that wraps SerpApi's public search API, exposing search, news, and image search as discrete MCP tools so any agent loop can fetch fresh web evidence without hand-rolling HTTP.

What I did

  1. 01

    Discrete MCP tools (search, news, images)

    Why: Each tool does one thing. An agent picks what it needs rather than parsing a single mega-response. Failure surfaces stay bounded per tool.

    Trade-off: More tools to maintain than one mega-tool. Per-tool audit clarity wins because debugging a mega-tool is where the time goes.

  2. 02

    Intent-filtered broker pattern

    Why: The broker surfaces the actual API call in response metadata. The agent (and the reviewer) can verify what was fetched without re-running the request.

    Trade-off: Slightly higher per-call overhead than a raw HTTP wrapper. The audit clarity earns the extra latency.

  3. 03

    Read-only by default

    Why: Search is read-only — there is nothing to mutate. Keeping the default read-only means a future feature that adds mutation has to go through the same opt-in ceremony as the rest of the bridge.

    Trade-off: None worth flagging. The pattern stays consistent with the other MCP bridges I ship.

What changed

  • Search API lock-in

    Before: Baked into the agent loop

    After: Swappable — SerpApi today, Bing tomorrow

  • Agent loop portability

    Before: Tied to SerpApi HTTP specifics

    After: MCP-portable across any agent framework

  • Evidence freshness

    Before: Up to 24h stale (model training cutoff)

    After: Live (real API call per retrieval)

Trade-offs

I depend on SerpApi's API uptime for the bridge to work. The bridge pattern means swapping providers when needed — the agent loop stays portable through the swap.

What I learned

Agent portability comes from MCP, not from the underlying API choice. The bridge is the abstraction layer that lets the search vendor change without rewriting the agent.

Stack

  • Go
  • MCP
  • SerpApi

Repository

https://github.com/louzt/serpapi-mcp ↗

Evidence

← Back to projects · curated 2026-09-20