La pregunta está mal formulada casi siempre. El MCP y la API no compiten: son dos momentos distintos del mismo camino.
Yo uso los dos cada día en Barner y en DigitalBrain, y tengo bastante clara la frontera. Empiezo con MCP para tantear. Acabo en API para producir. Aquí te cuento por qué, con lo que me ha pasado de verdad.
Qué es cada cosa
Un MCP es una conexión ya empaquetada entre Claude y una plataforma. La instalas, metes tu clave y Claude puede leer o escribir en esa herramienta. El trabajo de descubrir qué endpoints existen ya está hecho.
Una API es la puerta que la plataforma deja abierta para que cualquier programa hable con ella. Es lo que hay debajo del MCP, sin envolver.
O sea que un MCP es una forma cómoda de usar una API. Por eso enfrentarlos no tiene mucho sentido hasta que miras el detalle.
El patrón real: tanteo con MCP, produzco con API
No tengo una regla del tipo "esto una vez al mes va con MCP y esto a diario va con API". Lo que tengo es una secuencia.
Empiezo con el MCP porque quiero tantear un poco la plataforma. Ver qué puedo sacar. Ver qué puedo editar. Ver qué puedo escribir. Eso con la API en crudo te cuesta una tarde de documentación, y con el MCP lo tienes en cinco minutos.
Luego, poco a poco, el MCP se queda corto en alguna funcionalidad concreta. Y ahí empiezo a tirar de API.
El punto donde eso pasa casi siempre es el mismo: cuando empiezas a hacer automatizaciones y a conectar esa plataforma con otras herramientas que tú has creado. Ahí el MCP ya no llega y sí o sí tienes que ir por API.
Casi todo lo mío va por API directa
Voy a ser claro con esto porque va contra lo que se supone que debería decir alguien que escribe una guía sobre MCP.
En mi stack, casi todo lo que está en producción va por API directa. Las excepciones son dos: el MCP nativo del correo y el MCP de escritura de Beehiiv (y de este último uso una sola funcionalidad).
El motivo es simple: la API me da mucho más control y mucha más velocidad.
Dónde gana claramente el MCP
El correo. Ahí no hay discusión.
Con el MCP nativo de Gmail no necesito la API ni crear un app password para nada. Conecto y ya está leyendo, analizando y alimentando la memoria del negocio.
Hay un matiz que sí importa: cuando doy servicio a empresas haciendo consultoría, ahí sí necesito la API o el app password, sea de Microsoft o de Google, para acceder a esos correos y empezar a montar automatizaciones encima. El MCP nativo vale para tu propio correo, no para orquestar el de un cliente.
Dónde gana claramente la API
Dos casos reales, los dos de Barner.
El primero: la traducción de la web. Antes usábamos Langify y era un desastre. En varias ocasiones nos petó la página entera. Monté una API propia, la llamé Translate, y conecté Claude directamente a la herramienta de traducción nativa de Shopify. Aquí no usé el MCP en ningún momento. Y funciona perfecto.
El segundo: el stock. Cuando se acaba una referencia, pasa sola a borrador, o se desactiva, o se elimina, según toque. Con automatizaciones, sin que yo tenga que promptear nada. Un MCP necesita que alguien esté delante pidiendo cosas. Esto ocurre solo a las tres de la mañana si hace falta.
El caso que más dinero me ha devuelto
El otro día construí una herramienta para validar las facturas de un operador logístico. Sacamos vía API lo que sus escáneres habían leído en cada envío y lo cruzamos contra lo que nos habían facturado.
Resultado: unos 24.000 euros de sobrecostes entre enero de 2025 y julio de 2026. Nos estaban indicando pesos que no eran reales por problemas del escáner de sus instalaciones. Ya está reclamado.
Eso no lo hace un MCP. Necesitas bajar al dato crudo, cruzarlo tú, y tener el control de cada campo. Cuando alguien me pregunta para qué sirve la API directa, cuento esto.
Fíjate en lo que hizo falta: leer campo a campo dos fuentes distintas, mantener el criterio de comparación estable a lo largo de dieciocho meses de facturas, y poder repetir el cálculo cuando ellos respondieran. Eso es un programa, no una conversación.
Por qué la API me da velocidad
Hay una parte de esto que no es filosófica, es de reloj.
Cuando usas un MCP, le estás pasando a Claude todo el contexto de las herramientas disponibles antes de empezar a trabajar. Anthropic ha publicado que ha llegado a ver definiciones de herramientas ocupando 134.000 tokens antes de afinarlas, y que los resultados intermedios también pasan por el modelo.
Por API le pides exactamente el campo que quieres y te devuelve exactamente ese campo. Ni contexto de más, ni herramientas cargadas que no vas a usar.
Hay un punto intermedio que uso mucho y que te ahorra la elección: haces la acción con el MCP hasta que funciona, y luego le pides a Claude que te la construya en una skill. Gasta muchísimos menos tokens que el MCP y te la llevas donde quieras. Anthropic midió algo parecido en un caso de Google Drive a Salesforce: destilar el trabajo fuera del MCP lo dejó en 2.000 tokens desde 150.000.
Cuándo usar cada uno
Tira de MCP si estás explorando una plataforma nueva, si es tu propia cuenta, si la plataforma tiene server oficial, o si quieres resultado hoy sin pelearte con documentación.
Tira de API si vas a conectar esa plataforma con otras herramientas tuyas, si necesitas que la cosa se ejecute sola sin nadie delante, si te importa la velocidad, o si estás montando algo para un cliente.
Y hay una tercera vía que uso mucho: hacer la acción con el MCP hasta que funcione, y luego pedirle a Claude que te la construya en una skill. Gasta muchísimos menos tokens que el MCP y te la puedes llevar donde quieras.
Ninguna de las dos es la respuesta. La secuencia sí: tanteas con MCP y, cuando la cosa se pone seria, bajas a la API.
Cada día resumo lo que importa en IA en digitalbrain.email, y los miércoles va una formación práctica a fondo.
Relacionado
