El CTO de Perplexity acaba de decir que van a dejar atrás los MCPs y en su lugar se van a centrar en APIs y CLIS.
En respuesta, más empresas han empezado a posicionarse de manera similar.
Así que después del boom que hubo el año pasado… ¿están dejando de tener sentido los MCPs?
Respuesta corta: no.
Respuesta larga:
Para qué se creó MCP
El nombre de MCP es muy explícito: es un Protocolo para proveer de Contexto a nuestros Modelos.
Y eso es lo que vienen a resolver, añadir información a nuestros modelos que carecían hasta la fecha.
Ejemplos:
- Queremos que nuestro agente pueda acceder a nuestra base de datos para realizar peticiones.
- O acceder a nuestro sistema de logs.
- También es útil para añadir documentación a nuestros agentes de nuevas versiones de librerías con las que no han sido entrenados.
- Y para darle acceso a que controle nuestro navegador y pueda ver qué es lo que está programando.
Antes de los MCPs, con la capacidad que tenían los modelos, ni nos imaginábamos que podíamos hacer eso.
En el momento que salió el protocolo, empezamos a tratar a los agentes de una nueva manera.
Entonces… ¿qué es lo que ha cambiado en comparación con ese momento?
Lo que ha cambiado es simplemente que hemos ido utilizando cada vez más los agentes y hemos visto donde brillan y donde están sus limitaciones.
Limitaciones de los agentes
Una de las mayores limitaciones hoy en día es el contexto: cómo de larga puede ser una conversación.
Aquí no sólo influye todo lo que se ha conversado en una sesión, sino más cosas. Las relevantes:
- Cómo está configurado el agente: system prompt.
- Qué herramientas tiene disponible: leer un fichero, modificarlo….
- Qué MCPs tiene disponible: ahora entraremos en detalle.
- Qué Skills tiene disponible: también hablaremos de esta parte.
Y aquí es donde los MCPs tienen un gran problema: pueden llegar a consumir mucho contexto.
Por ejemplo, Claude Code tiene 14 herramientas nativas. Cada herramienta ocupa un poco de contexto, ya que tiene que decir qué es, cómo se usa y cuándo se ha de llamar.
Lo mismo pasa con los MCPs. Uno de los más famosos es el de Playwright, que sirve para controlar el navegador. Este incluye, a día de hoy, más de 25 herramientas y todas son necesarias:
- Para navegar a una URL.
- Hacer click en elementos.
- Ejecutar JS en la página.
- Y mucho más.
Esas más de 25 herramientas consumen mucho contexto (quizás un 10% del total disponible).
Si a eso le sumas otros MCPs, te quedas sin contexto en muy poco tiempo.
A esto se le suma que los agentes se pueden confundir y llamar a la herramienta que no toca.
Por ejemplo, en lugar de abrir un fichero, llaman a abrir un fichero en el browser. Cosa que hace que el agente trabaje peor ya que tiene que dar más vueltas para conseguir lo mismo.
Para combatir esto, la mayoría de sistemas de agentes tomaron 2 medidas:
- Poder activar y desactivar MCPs al vuelo.
- Añadir una herramienta para buscar otras herramientas. Así no se carga la definición de todas las herramientas del MCP en el contexto inicialmente, sino que el agente busca dinámicamente si tiene herramientas disponibles.
Con todo esto el uso de MCPs mejoró bastante. Lo que pasa es que en paralelo nos dimos cuenta de otra cosa.
Los agentes son MUY buenos usando el CLI
Aquí el ejemplo más evidente es el uso de gh, la herramienta de GitHub para la terminal.
En su momento GitHub sacó su propio MCP y fue uno de los primeros que todos nos pusimos a instalar. Hasta que nos dimos cuenta de que los agentes podían hacer lo mismo usando gh, de una manera más óptima (menos consumo de tokens) y rápida.
Esto hizo que nos diéramos cuenta de que muchos MCPs que eran wrappers de CLIs no tenían sentido. Si le dabas al agente acceso directo a la CLI, iba mucho mejor y encima quitabas un nivel de indirección.
Pero aquí había un problema: esto funcionaba para CLIs con los que los modelos habían sido entrenados, pero para nuevos, no. Aquí es donde llegó una nueva pieza.
Las Skills
Resumidamente, una Skill es un markdown con instrucciones. Una forma de proveer contexto a nuestros modelos, pero más simple y más fácil de compartir entre personas.
Con las Skills no hace falta crear un servidor MCP para hacer un wrapper de una herramienta de CLI.
Simplemente documentando cómo funciona en la propia Skill, los agentes ya sabrán como utilizarla.
Por ejemplo, si los modelos no hubieran sido entrenados para usar gh, podríamos crear rápidamente una Skill para ello:
---
name: gh
description: Use the official GitHub CLI to create issues, PRs…
---
You have the `gh` CLI installed. To see its usage, run `gh --help`.
…
De esta forma ya sabría usar todas las herramientas de la CLI de GitHub.
A destacar: la Skill también consume contexto inicial, pero sólo la parte que tiene el campo description del frontmatter. Mucho menos que la descripción de cada herramienta de un MCP.
Lo mismo pasa con MCPs que eran wrappers de APIs HTTP. Se puede crear una Skill que explique qué endpoints hay y cómo usarlos.
Así que con todo esto, surge la pregunta…
¿Entonces ya no tienen sentido los MCPs?
Viendo que ya no sirven de wrappers de CLIs ni de APIs, puede parecer que ya no tienen tanto sentido, pero no es así. Aún hay un caso interesante: Code Mode.
El Code Mode es un patrón inventado por Cloudflare (y también explorado por Anthropic).
La idea: darle al agente la posibilidad de llamar a APIs enormes (de cientos a miles de endpoints) sin tener que entrenar un modelo para cada uno de ellos ni exponer todo en el contexto.
Esto se consigue exponiendo 2 herramientas:
- Search:
- Busca en el esquema OpenAPI de la API y encuentra qué endpoint usar.
- Es una búsqueda semántica. Por ejemplo, dices "quiero ver qué dns hay en mis zonas" y te dice qué endpoints usar para ello.
- Lo que devuelve es un esquema JS para que el agente pueda llamar a la API.
- Al ser un JS, se pueden combinar llamadas.
- Execute:
- Se le envía código para que se ejecute en el servidor.
- Ese código se ejecuta en un sandbox.
- Un ejemplo podría ser:
const zones = await cloudflare.zones.list();
const zoneId = zones[0].id;
const records = await cloudflare.dns.records.list({ zone_id: zoneId });
return records.filter((r) => r.type === "A");
Aquí lo importante es que en mi servidor no tengo instalada ninguna librería cloudflare, pero el agente sabe que puede usarla dinámicamente y enviar ese código al MCP para tener la respuesta esperada. Todo esto sin tener que conocer todos los endpoints que tiene internamente.
Ahora te podrías preguntar: Esto podría ser una Skill, ¿no?
Y la verdad es que es una muy buena pregunta ya que podría parecer que sería tan sencillo como crear un markdown con la definición de esos 2 endpoints y ya lo tendríamos.
En este caso, la gente de Cloudflare también tiene su Skill para ello, aunque no se basa en estos endpoints.
¿Entonces qué ventaja tiene el MCP frente a la Skill?
La ventaja es qué pasa si cambia la forma de funcionar de mis APIs.
Qué pasa si ahora añaden una tercera herramienta de validate que hay que llamar antes que execute. Con la Skill no nos enteraríamos automáticamente del cambio.
Aquí es donde los MCPs siguen teniendo relevancia. La definición de sus herramientas es dinámica: se carga cada vez que consultas qué herramientas hay disponibles. Si algo cambia, el agente siempre tendrá la última versión.
En una Skill te basas en tener un sistema que te la vaya manteniendo actualizada. Aún no hay un estándar para ello.
Además, hay otras ventajas de usar MCPs:
- Si no tienes una API 100% HATEOAS, te permite facilitar las llamadas.
- Permite fácilmente añadir restricciones. Por ejemplo, MCP de Postgres que sólo permita hacer peticiones de lectura. Si le decimos que en lugar use el CLI, le hemos de crear un usuario con los permisos mínimos.
- Tiene autenticación de forma nativa. Mejor UX para sitios donde haga falta hacer login que vs CLI.
- MCP APPs te permite integrar elementos tuyos en otros sistemas.
- Es probable que cada vez hablemos más de WebMCP.
Así que sí, pese a que las Skills se hayan comido bastante terreno de los MCPs, hoy en día, siguen siendo relevantes.