El mes pasado vi a un equipo pasar nueve días construyendo un MCP server para obtener datos meteorológicos. Nueve días. El agente podría haber golpeado la API con un solo curl y una definición de herramienta de una línea. Pero MCP era lo brillante, así que MCP fue.
Permíteme decir en voz alta lo que nadie dice: deberías dejar de construir MCP servers para todo. El Model Context Protocol es genuinamente bueno. También está salvajemente sobreutilizado por personas que oyeron "estándar" y asumieron "obligatorio."
Para qué sirve realmente MCP
MCP resuelve un problema real: tienes una capacidad que quieres exponer a muchos agentes, en muchos clientes, con una interfaz consistente. Piensa en una base de datos que toda la organización consulta. Un sistema de diseño. Un índice de búsqueda interno que doce herramientas distintas necesitan usar. Construyes el server una vez, y Claude Desktop, Cursor y tu harness personalizado hablan con él de la misma manera. Esa es la victoria. Reutilización entre clientes.
Eso es todo. Esa es la propuesta completa. Si no estás obteniendo reutilización entre múltiples clientes o múltiples agentes, estás pagando el impuesto del protocolo para nada.
El impuesto que nadie menciona
Cada MCP server es un proceso. Tiene un ciclo de vida. Tiene un transporte — stdio o SSE — que puede bloquearse, caerse o dejar de responder silenciosamente. Carga las definiciones de herramientas en tu ventana de contexto tanto si las llamas como si no. He visto un MCP server parlanchín consumir 4.000 tokens de contexto antes de que el modelo lea una sola palabra de la tarea real.
Y tienes que mantenerlo. Versionarlo. Gestionar la autenticación dentro de él. Depurarlo cuando el agente dice "la herramienta no responde" y no tienes ni idea de si es el server, el transporte o el modelo alucinando un nombre de herramienta.
Compara eso con una función simple que el agente llama directamente, o un comando CLI que ejecuta desde Bash. Cuando mi agente de Claude Code necesita golpear la API de GitHub, ejecuta gh. Ningún server. Ningún protocolo. Ningún ciclo de vida. La herramienta ya está en la máquina y el modelo ya sabe cómo manejarla.
La regla de decisión honesta
Esta es la prueba que uso realmente antes de escribir una sola línea de código de server:
- ¿Usará esto más de un cliente o agente? Si no, omite MCP.
- ¿Existe ya un CLI que lo haga? Si sí, deja que el agente ejecute el CLI.
- ¿Es una integración puntual para un proyecto? Escribe una herramienta local, no un server.
- ¿Necesitas que sobreviva a este repositorio y sea compartido? Ahora tiene sentido MCP.
Fíjate en cuántas veces la respuesta es "omitir MCP." Para un builder en solitario lanzando un producto, la respuesta es casi siempre omitir. No tienes muchos clientes. Tienes uno. Estás construyendo infraestructura para una flota que no posees.
La trampa del wrapper
El MCP server malo más común es el wrapper de API. Alguien toma una API REST que ya está bien documentada, ya tiene una spec de OpenAPI, ya funciona con un bearer token, y la envuelve en MCP. ¿Por qué? El agente podría leer la spec. Podría hacer la petición. Has añadido una capa de traducción entre el modelo y algo en lo que el modelo ya era bueno.
Peor aún, ahora has ocultado la superficie real de la API detrás de las definiciones de herramientas que elegiste a mano. La API tiene 40 endpoints. Tu server expone 6, porque esos eran los que necesitabas el martes. Ahora el agente literalmente no puede hacer las otras 34 cosas sin que envíes una nueva versión del server.
Si la cosa subyacente es una API HTTP, prueba esto primero:
# Deja que el agente la llame directamente
curl -s https://api.example.com/v1/items \
-H "Authorization: Bearer $TOKEN" | jq '.items'
Dale al modelo la URL base, el patrón de autenticación y la documentación. Observa cómo funciona. Te sorprenderá la frecuencia con que el requisito de "necesitamos un MCP server" desaparece.
Cuándo sí uso MCP
No soy anti-MCP. Construí uno para un vector store que cuatro agentes independientes consultan, con lógica de embedding compartida que no quería reimplementar cuatro veces. Ese es el punto óptimo: estado compartido real, múltiples consumidores reales, coste real de duplicar la lógica. El protocolo se ganó su lugar.
También lo uso cuando la capacidad necesita ser stateful de una manera que un CLI sin estado no puede gestionar bien — un pool de conexiones de larga duración, un índice en caché, una sesión de autenticación cara de restablecer. El server mantiene el estado. Los agentes lo toman prestado. Buen encaje.
Pero esos son casos concretos. No son "cada integración." El default debería ser: herramienta directa, o CLI, o una función simple. MCP es la escalada, no el punto de partida.
El problema del desarrollo guiado por el currículum
Seamos honestos sobre por qué ocurre esto. MCP es nuevo y está de moda, y "construí un MCP server" suena mejor en una reunión diaria que "escribí una definición de herramienta de 12 líneas." Lo entiendo. El incentivo es construir lo que suena impresionante.
Pero a tus usuarios no les importa tu arquitectura. Les importa si el agente lanzó la funcionalidad. Cada hora que pasas construyendo fontanería de protocolo para una integración de consumidor único es una hora que no pasaste en el producto. La jugada más sénior suele ser la más aburrida: omite el server, llama a la API, sigue adelante.
Construye el MCP server cuando tengas muchas bocas que alimentar. Hasta entonces, tu agente tiene una shell. Déjala usarla.