MCP no reemplaza a las APIs. Lo que cambia es quién decide la llamada: tú o el modelo. Ese es el único criterio que uso para elegir.
Me preguntan seguido si MCP viene a reemplazar las APIs, y la comparación no es esa. Casi todo servidor MCP que he abierto por dentro termina llamando a la misma API de siempre.
MCP es un protocolo para exponerle herramientas a un modelo de forma estándar. Debajo sigue habiendo peticiones HTTP, tokens, límites de uso y respuestas con el formato raro de siempre. Uno vive encima del otro, no uno en lugar del otro.
Entonces la pregunta útil no es cuál es mejor. Es esta: en tu caso, ¿quién decide qué llamada se hace y en qué orden? Si lo decides tú cuando armas el flujo, es una cosa. Si lo decide el modelo en el momento, es otra.
Si ya sabes qué llamada tiene que pasar, en qué orden y con qué datos, no necesitas que un modelo lo decida por ti.
Un proceso que siempre hace lo mismo (llega un lead, se valida, se crea el contacto, se dispara el correo) es un camino fijo. Ahí un llamado HTTP dentro de un flujo de automatización te da tres cosas que un agente no: sabes exactamente qué se ejecutó, cuesta lo mismo siempre y no depende de que el modelo se despierte de buenas.
También pesa el tema de auditoría. Cuando el cliente pregunta por qué a ese contacto le llegó ese mensaje, en un flujo lo sigues paso a paso. Con un agente decidiendo, primero tienes que reconstruir por qué eligió esa herramienta y no otra.
Mi regla: si puedes dibujar el proceso en una servilleta sin usar la palabra depende, déjalo en un flujo.
MCP empieza a ganar cuando la decisión no la puedes tomar tú de antemano.
El primer caso es el agente conversacional. Alguien le escribe y puede pedir cualquier cosa: consultar una tarea, crear otra, buscar un cliente, revisar el calendario. No hay un orden fijo posible porque el orden lo pone quien pregunta. Cablear eso como flujo te obliga a adivinar todas las rutas, y siempre falta una.
El segundo caso es el reuso. Si armas la integración una vez como servidor MCP, la conectan varios agentes y varios clientes distintos sin volver a cablear nada. Cuando tienes tres o cuatro agentes que necesitan tocar el mismo sistema, ese ahorro sí se nota.
El tercero es más práctico y es el que más uso: herramientas que quiero tener a la mano mientras trabajo, no dentro de un proceso. Consultar mi base de conocimiento, revisar el estado de un servidor, mirar métricas. No es un proceso que corre solo, es algo que le pido cuando lo necesito.
La promesa de que MCP te ahorra la integración me suena a demo. El trabajo no desaparece, se corre de lugar.
Hace poco estaba conectando una herramienta con una llamada HTTP normalita y me devolvía ciento sesenta y un elementos sueltos donde yo esperaba una sola lista con todo adentro. Mirando el output dos minutos uno lo cacha y ajusta. Un modelo no tiene de dónde sacar ese detalle si nadie se lo escribió.
Ese es el punto. Con una API tú lees la respuesta rara y la acomodas una vez. Con MCP tienes que explicarle por escrito al modelo qué devuelve, cuándo sirve y cuándo no la use. El trabajo pasó de escribir la llamada a documentarla bien, y esa parte casi nadie la muestra.
En la práctica, una herramienta mal descrita es peor que no tenerla: el modelo la va a usar cuando no toca, y vas a estar depurando por qué hizo algo que nunca le pediste.
Cada herramienta que le conectas ocupa espacio en el contexto del modelo y le suma una opción más para equivocarse. Un agente con seis herramientas bien escogidas acierta más que uno con cuarenta conectadas por si acaso.
Y está el tema de permisos, que es el que más me preocupa en cuentas de clientes. Cuando le entregas una herramienta a un agente, le estás entregando la capacidad de ejecutarla sin que nadie apruebe cada vez. Lo que borra, lo que manda hacia afuera y lo que mueve plata no va por ahí, o va con confirmación humana de por medio.
Por eso yo arranco al revés de como suele hacerse: la lista de herramientas empieza vacía y solo entra la que ya me hizo falta dos veces.
Cuando tengo que elegir, me hago cuatro preguntas y con eso me alcanza.
Uno: ¿el orden de las llamadas lo sé yo de antemano? Si la respuesta es sí, va en un flujo con llamado normal. Dos: ¿esto lo van a usar varios agentes o varios clientes? Si es sí, MCP empieza a pagar el trabajo extra.
Tres: ¿qué pasa si se ejecuta cuando no debía? Si la respuesta incomoda, no se la entrego suelta al agente. Cuatro: ¿puedo explicar en dos líneas para qué sirve y cuándo no usarla? Si no puedo, el problema no es el protocolo, es que todavía no entiendo bien la herramienta.
Con eso, casi todo lo que tiene un camino fijo termina en API pura dentro de un flujo, y MCP me queda para lo que de verdad decide el modelo. No es una postura en contra de MCP, es que cada uno resuelve un problema distinto y confundirlos sale caro.