Cómo Construir un Servidor MCP de Producción: OAuth, Límites de Tools y Estado
Una demo local de MCP puede ser poco más que un transporte y algunas funciones. Un servicio MCP de producción es otro tipo de sistema: tiene identidades, credenciales, límites de autorización, estado persistente, APIs externas y modos de falla que un cliente de AI puede disparar repetidamente. El protocolo es sólo una capa del diseño.
Tratar al servidor MCP como un límite de aplicación
La forma más fácil de construir una integración MCP es exponer una API existente casi directamente. También es una forma fácil de darle a un cliente de AI más autoridad de la que necesita. En producción prefiero tratar al servidor MCP como un límite de aplicación propio, con un contrato deliberadamente pequeño.
En Search Console Insights las operaciones útiles son específicas: descubrir propiedades conectadas, consultar rendimiento de búsqueda, comparar períodos, inspeccionar indexación de URLs y leer el estado de sitemaps. El servidor expone esos flujos en lugar de convertirse en un proxy genérico para cualquier operación de Google.
Diseñar tools alrededor de la intención, no de los endpoints externos
Una buena tool debería representar una tarea sobre la que el asistente pueda razonar. Normalmente eso significa menos parámetros, resultados más acotados y defaults más fuertes que los que ofrece la API externa.
Por ejemplo, una tool de rendimiento puede limitar dimensiones, rangos de fechas y cantidad de filas. El modelo conserva suficiente flexibilidad para analizar tráfico, pero no puede pedir datos sin límite ni invocar operaciones de Search Console que no forman parte del producto.
const SearchPerformanceInput = z.object({
siteUrl: z.string().min(1),
startDate: z.string(),
endDate: z.string(),
dimensions: z.array(
z.enum(["date", "query", "page", "country", "device"])
).max(3),
rowLimit: z.number().int().min(1).max(25000),
});OAuth es parte de la arquitectura, no una pantalla de login
Un servicio MCP remoto necesita saber quién lo está llamando y qué cuenta externa puede usar esa identidad. Eso convierte a OAuth en parte de la arquitectura del servicio, no en una capa superficial de autenticación delante de las tools.
En este proyecto el cliente MCP se autentica contra el servicio mientras los refresh tokens de Google permanecen del lado del servidor. El cliente recibe las capacidades que expone MCP, no las credenciales de Google. Esa separación reduce exposición y crea un lugar estable para aplicar autorización.
Separar datos externos del estado del workflow
No todo dato que pasa por un servidor MCP debería terminar en su base. Los datos de rendimiento de Search Console pueden leerse desde Google y cachearse brevemente sin convertirse en datos propios de la aplicación.
La persistencia tiene más sentido para el estado que el usuario crea dentro del flujo: acciones SEO planificadas, notas de implementación e historial de cambios. Separar esas categorías reduce retención innecesaria y deja claro qué sistema es autoritativo para cada registro.
El aislamiento necesita algo más que un user ID
Cuando existe estado persistente, cada registro necesita un límite de ownership explícito. En Search Console Insights, los registros del workflow quedan aislados por el subject autenticado de Google y por la propiedad de Search Console a la que pertenecen.
Esto importa porque una persona puede acceder a varias propiedades y el servicio puede soportar múltiples identidades conectadas. La autorización tiene que responder tanto quién hace el request como a qué propiedad pertenece el estado solicitado.
Limitar las operaciones que un agente puede repetir
Los clientes de AI son muy buenos componiendo tools, pero también pueden reintentar, ampliar una consulta o repetir una operación muchas veces mientras exploran un problema. Las tools de producción deberían asumir que ese comportamiento es normal.
Por eso establezco límites explícitos sobre rangos de fechas, tamaños de resultados y dimensiones soportadas, valido cada input y evito fetch arbitrario de URLs externas. No son restricciones especiales para modelos; son controles normales de backend aplicados a un cliente que en este caso es un sistema de AI.
El comportamiento ante fallas es parte del contrato
Una tool MCP debería fallar de una forma que el cliente pueda entender sin exponer secretos ni detalles internos. Los errores de APIs externas, autorizaciones vencidas y fallas de base necesitan límites útiles, mientras que credenciales, strings de conexión y stacks internos deben quedar en el servidor.
Esto también mejora el comportamiento del agente. Un error claro y acotado le da información suficiente para elegir otra acción. Un crash opaco incentiva reintentos; un error de infraestructura demasiado detallado puede filtrar información que el cliente nunca necesitó.
Probar por separado el protocolo y la aplicación
Hay al menos dos cosas distintas para verificar: la lógica de backend detrás de cada operación y el transporte MCP que la expone. Type checking y tests unitarios cubren validación y comportamiento del servicio; los smoke tests del protocolo verifican que un cliente MCP real pueda inicializar el servidor, descubrir tools e invocarlas.
Esa separación acelera mucho el diagnóstico. Si la lógica del servicio pasa pero falla el descubrimiento de tools, el problema está en la capa de protocolo. Si el transporte funciona pero falla una consulta de Search Console, la investigación pasa a autenticación, validación o la API externa.
MCP en producción es backend engineering con un cliente nuevo
La parte interesante de un servidor MCP no es la novedad del tool calling. Las partes difíciles son problemas conocidos de backend: autenticación, autorización, contratos, límites de uso y tamaño, ownership del estado, persistencia, observabilidad y fallas seguras.
El cliente de AI cambia cómo se descubren y combinan esas capacidades, pero no elimina la necesidad de diseñar el servicio con disciplina. Mi regla es simple: darle al agente capacidades útiles y hacer los límites alrededor de esas capacidades suficientemente explícitos para que el sistema siga siendo entendible cuando opera sin supervisión constante.
Trabajo relacionado
Ver la arquitectura de producción detrás de Search Console Insights