Los MCPs no estaban muertos, estaban de parranda

Hay una extraña obsesión por matar a los MCP servers (Model Context Protocol) que no termino de entender.

Es cierto que en su momento fueron sobre-utilizados. Estábamos en los inicios de los agentes de IA, y fue una de las grandes revoluciones.

Y cuando tienes un martillo y quieres usarlo, ves clavos por todas partes.

Y no, no todo eran clavos.

En las últimas semanas hemos visto cómo las redes ardían pidiendo su cabeza. Incluso se han organizado “Funerales por los MCPs”.

Pero no, a los MCPs les queda mucha vida. Mi predicción es que en el futuro cada empresa tendrá su API y su MCP.

Al final te contaré por qué. Pero de momento, vamos a hacer un poco de historia.

¿Qué son los MCPs?

Por si llega algún despistado, MCP es un protocolo que creó Anthropic y posteriormente se estandarizó. Lo vendieron como el USB-C de la IA.

Antes, cuando querías conectar un agente a un servicio externo, te tocaba picarte tu propio agente y tus propias tools a mano, y estas no eran reutilizables en ningún otro agente.

Seguro que has visto, e incluso usado algunas de las integraciones que hicieron ChatGPT y compañía. Todo eso era implementado a mano.

Las APIs de los LLMs ofrecen el concepto de tools, que consiste en que tú le explicas al modelo que tiene unas tools que puede usar, y una descripción sobre cuándo usarlas. El modelo te avisa de cuándo quiere llamarlas, tú las llamas por código y le devuelves el resultado.

Pero esto no escala, porque está muy incrustado en el código de tu agente.

Con el objetivo de estandarizar esa comunicación, surge el protocolo MCP. Un cliente implementa el protocolo, y entonces ya sabe usar los MCP servers. Independientemente de cómo lo haga, si cliente y servidor cumplen el protocolo, se pueden comunicar entre sí.

Estos MCPs ofrecen tools.

Algunos muchas tools.

Muchísimas.

El problema de los MCPs

Los MCPs inundaron el mundo, principalmente el de desarrolladores. Se decía (medio en broma, medio en serio) que había más MCP servers que usuarios 😄

Pero tenía un problema: inundaban el contexto.

Cada MCP ofrece unas tools, y cada definición de tools tiene un montón de información sobre cómo llamarla, sus argumentos, el tipo de los mismos, para qué sirve cada uno…

En MCPs grandes, esto consumía un montón de ventana de contexto.

Un caso muy anecdótico era el MCP de GitHub. Cuando se lanzó Copilot CLI, que venía con el MCP de GitHub instalado, la ventana de contexto ya empezaba ocupada en un 35%. Un despropósito.

Los CLIs llegan al rescate

Aquí hubo alguna gente que se empezó a dar cuenta de que esto de los MCPs se nos estaba yendo de las manos.

El caso de GitHub fue muy anecdótico, y de hecho hice un vídeo al respecto: ¿qué sentido tiene usar un MCP, cuando un CLI está ahí, el agente puede descubrirlo llamando a --help, e incluso para los más populares el agente sabe usarlos sin ninguna instrucción?

Tú pídele a cualquier agente que use gh, y lo hará sin inmutarse.

Obviamente para algunos casos eran algo más lentos, si era un CLI propio o poco conocido, y había que hacer algunos truquillos como añadir un pequeño contexto permanente que explicar cómo usar lo básico del CLI.

Pero llegaron las skills.

Y entonces ya sí, los MCPs empezaron a agonizar.

Las skills vienen a cambiarlo todo

Las skills son un concepto muy interesante a nivel lógico: un contexto que se carga dinámicamente solo cuando el agente lo necesita.

De un plumazo, todos esos MCPs que hacían 4 peticiones simples a una API desaparecieron.

Todos esos MCPs que imitaban un CLI, y que aún eran mejor porque los agentes no sabían usarlos, también desaparecieron.

La fiebre de la skill hizo que todo el mundo se pusiera a convertir los MCPs en skills, o en CLI + skill.

¿Entonces qué? Nos cargamos los MCPs

A los desarrolladores nos suele pasar que nos creemos que NUESTRO mundo es EL mundo. Y no es así para nada.

Imagina que Paco el panadero descubre esto de los agentes de IA. Yo qué sé, lee por ahí que Claude Desktop mola mucho y que le puede ayudar con su facturación.

Y se lo instala en su ordenador.

Ahora explícale a Paco que tiene que irse a buscar un CLI de la herramienta que use para contabilidad, instalarlo, y buscar una skill (o incluso crearse la suya propia) que explique al agente cómo usarla.

Luego también dile que de vez en cuando debería actualizar el CLI y la skill, porque a lo mejor la API de esa herramienta ha cambiado.

Y así con todas las herramientas que quiera integrar con su agente.

Ya el propio paso de instalarse Claude Desktop puede ser una fricción. Imagina que usa la App de Claude del móvil, o ChatGPT. ¿Cómo instala un CLI ahí? No puede, por razones obvias.

Pero, ¿y si en vez de eso existiera una store de Apps o conectores dentro de estas herramientas donde, en un click, se puedan instalar y empezar a usar el servicio?

Pues esto no es ciencia ficción. Existe, y adivina… Esas Apps son MCPs.

Los MCPs no se van a ninguna parte. De hecho, se vienen upgrades

Esto que te he contado es solo una pequeña parte de lo que se viene.

No hace mucho, se añadió al protocolo la opción de permitir que los MCPs sirvan UI que se pueda mostrar en el cliente.

Ya hay algunos MCPs que lo utilizan, y esto, de nuevo, estandariza la forma de mostrar interfaces gráficas dentro de los agentes.

Si el futuro, como dicen, consistirá en interactuar constantemente con un chatbot, para tareas más complejas necesitaremos una interfaz, y esta se puede generar dinámicamente a través de un MCP.

Como programador quizá no los uses, pero tu empresa los necesita

Muchas veces nos cuesta ver más allá de las tecnologías que usamos en nuestro día a día.

Pero si nos abstraemos un poco, nos daremos cuenta de que esas no son herramientas de consumo habitual, y que para el gran público necesitamos opciones más sencillas.

Las tiendas de MCPs (que por supuesto no llamarán así) van a ser la norma en el futuro, y que el producto de las empresas para las que trabajas tenga su MCP allí publicado va a ser una ventaja competitiva grande.

E incluso si no es así, hoy en día ya tanto ChatGPT como Claude te dejan instalar tus propios MCPs.

En mi proyecto de Postflow he estado adaptando el MCP para que funcione en estos entornos. Porque si quieres llegar al gran público, tarde o temprano vas a tener que estar ahí.

En fin, todo este rollo para contarte que creo que los MCPs no se van a ninguna parte, y que dediques un tiempo a entenderlos y saber utilizarlos.

Los vas a necesitar.