Cuando no necesitas MCP: el coste real de cada servidor

Un servidor MCP mínimo en TypeScript cabe en unas cuarenta líneas. Lo que no cabe en cuarenta líneas es su coste operativo: un proceso más que arrancar, un handshake de inicialización, un ciclo de vida que vigilar y, sobre todo, un catálogo de herramientas que el modelo lee entero al abrir cada conversación. Diez tools con descripciones generosas se llevan un par de miles de tokens de ventana antes de que el usuario haya escrito la primera palabra.

HackerNoon publicó este 10 de septiembre una guía práctica sobre cuándo no necesitas MCP, escrita desde el lado de quien ya lleva meses montando integraciones. La tesis va a contracorriente del entusiasmo del último año: el Model Context Protocol resuelve un problema de distribución y descubrimiento, no un problema de capacidad. Si no tienes ese problema, estás pagando la factura sin recibir la mercancía.

Qué resuelve MCP de verdad

MCP estandariza la forma en que un cliente que tú no controlas, sea Claude Desktop, Claude Code o un IDE de terceros, descubre herramientas, lee sus esquemas y las invoca. La palabra que importa es descubre. El cliente no sabía nada de tu API, arranca el servidor, pide la lista de tools, recibe nombres, descripciones y JSON Schema, y ya puede usarlas sin que nadie recompile ni vuelva a desplegar.

Ese contrato vale dinero cuando existe una frontera real entre quien escribe la herramienta y quien la consume. Si tu agente y tus funciones viven en el mismo repositorio, se despliegan juntos y solo los llama tu propio backend, esa frontera no existe. Lo que has introducido es un protocolo de red entre dos módulos que podían hablarse con una llamada a función.

Los casos en los que sobra

Una herramienta y un consumidor. Si expones una sola operación y solo la usa tu agente, una función con su docstring hace el mismo trabajo sin transporte de por medio.
Flujo determinista. Cuando el orden de los pasos lo decide tu código y no el modelo, no necesitas que elija herramienta: necesitas un script.
Datos que ya tienes. Si el contenido cabe en el prompt y no cambia durante la sesión, inyectarlo sale más barato y más predecible que una llamada.
Latencia sensible. Cada salto añade serialización, ida y vuelta y una decisión del modelo. En interacción con usuario final eso se nota.
Superficie de tools inflada. El coste no es solo el token. Cuantas más herramientas parecidas ve el modelo, peor elige entre ellas.

Ese último punto es el que más nos hemos encontrado en auditorías: equipos con cinco servidores MCP conectados, cuarenta tools visibles en el prompt y un agente que confunde dos herramientas con nombres casi idénticos.

Cuándo sí compensa

El artículo no es un alegato contra MCP, y nosotros tampoco lo firmaríamos. El protocolo gana en cuanto aparece alguna de estas condiciones:

Varios clientes distintos consumen las mismas herramientas y no quieres reimplementarlas en cada uno.
El catálogo cambia con más frecuencia que el agente y te interesa desplegarlos por separado.
Hay autenticación delegada, con OAuth y credenciales que no deben pasar nunca por el prompt.
* Distribuyes a terceros: alguien instala tu servidor sin ver tu código.

En el ecosistema de Claude Code hay además un factor práctico que el artículo no cubre. Skills, subagentes y hooks resuelven buena parte de lo que la gente acaba montando como servidor. Una skill empaqueta instrucciones y contexto y no ocupa ventana hasta que se invoca. Un hook en PostToolUse valida una escritura sin exponer nada al modelo. Un subagente aísla una tarea larga sin contaminar la conversación principal. Antes de abrir un repositorio nuevo para un servidor, merece la pena descartar esos tres.

La pregunta de los cinco minutos

No es si MCP mola. Es esta: ¿quién más va a llamar a esta herramienta y quién la va a desplegar? Si las dos respuestas son la misma persona en el mismo sitio, escribe la función. Si alguna incluye a alguien que no controlas, monta el servidor. Y una segunda, igual de barata: ¿necesita el modelo elegir? MCP existe para que un LLM decida entre opciones con información suficiente. Si la elección ya está tomada en tu código, el protocolo solo añade ceremonia.

Nuestra posición después de unas cuantas integraciones es que MCP es infraestructura, y la infraestructura se justifica por reutilización, no por elegancia. Cuando un cliente nos pide un servidor, la primera media hora se va en comprobar si lo que necesita es un servidor o una función bien documentada.