louzt/serpapi-mcp

El reto

Los loops agénticos necesitan evidencia web fresca para verificar afirmaciones. Bakear una API de búsqueda específica en el agente crea lock-in; construir mi propio bridge desde cero cuesta tiempo de ingeniería que preferiría invertir en el agente mismo.

Mi rol

Construí un servidor MCP basado en Go que envuelve la API pública de SerpApi, exponiendo búsqueda, news y búsqueda de imágenes como herramientas MCP discretas para que cualquier loop agéntico pueda fetchar evidencia web fresca sin tener que armar HTTP a mano.

Lo que hice

1. 01

   Herramientas MCP discretas (búsqueda, news, imágenes)

   Por qué: Cada herramienta hace una cosa. Un agente escoge lo que necesita en lugar de parsear una mega-respuesta. Las superficies de fallo quedan acotadas por herramienta.

   Trade-off: Más herramientas que mantener que una mega-tool. La claridad de auditoría por herramienta gana porque debuggear una mega-tool es donde se va el tiempo.

2. 02

   Patrón de broker con intent-filter

   Por qué: El broker expone la llamada real a la API en la metadata de respuesta. El agente (y el reviewer) pueden verificar qué se fetcheó sin re-correr el request.

   Trade-off: Overhead por llamada ligeramente mayor que un wrapper HTTP crudo. La claridad de auditoría gana la latencia extra.

3. 03

   Read-only por default

   Por qué: Búsqueda es read-only — no hay nada que mutar. Mantener el default read-only significa que una futura funcionalidad que añada mutación tiene que pasar por la misma ceremonia de opt-in que el resto del bridge.

   Trade-off: Ninguno que valga la pena marcar. El patrón se mantiene consistente con los otros bridges MCP que entrego.

Lo que cambió

• Lock-in de API de búsqueda

  Antes: Bakeado en el loop del agente

  Después: Swappable — SerpApi hoy, Bing mañana

• Portabilidad del loop del agente

  Antes: Atado a los detalles HTTP de SerpApi

  Después: MCP-portable a través de cualquier framework de agente

• Frescura de la evidencia

  Antes: Hasta 24h stale (corte de entrenamiento del modelo)

  Después: Live (llamada real a la API por retrieval)

Trade-offs

Dependo del uptime de la API de SerpApi para que el bridge funcione. El patrón de bridge significa swap de providers cuando haga falta — el loop del agente se mantiene portable a través del swap.

Lo que aprendí

La portabilidad del agente viene del MCP, no de la elección de API subyacente. El bridge es la capa de abstracción que permite que el vendor de búsqueda cambie sin reescribir el agente.

Stack

• Go
• MCP
• SerpApi

Repositorio

Evidencia

• Repositoryhttps://github.com/louzt/serpapi-mcp ↗