La llegada de Web 2.0 2.0: MCP
(anildash.com)- Model Context Protocol (MCP) es una especificación creada por Anthropic para conectar los LLM con apps y sistemas externos, y después de que OpenAI la adoptó en ChatGPT, se ha extendido como una interfaz común entre múltiples plataformas
- Incluso si la especificación es flexible e incompleta, cuando varios participantes adoptan rápidamente la misma forma de trabajar, los protocolos abiertos pueden ganar fuerza en la web real
- El valor original de la Web 2.0 estaba más cerca de un ecosistema de desarrolladores y usuarios creado por APIs abiertas y herramientas interoperables que de sitios sociales cerrados
- La expectativa de interoperabilidad que se debilitó cuando grandes plataformas como Facebook y Twitter cerraron sus APIs podría revivir con MCP como una plataforma programable dentro del auge de las herramientas de programación con IA
- MCP no es una solución universal y también implica falta de transparencia en el manejo de datos y riesgos de seguridad, pero puede convertirse en un nuevo punto de partida para exigir cumplimiento de estándares y transparencia
Por qué MCP se ha expandido como si fuera un estándar
- Model Context Protocol, es decir, MCP, es una especificación diseñada por Anthropic para Claude
- Su objetivo es permitir que los LLM soliciten información a distintas apps o interactúen con otros sistemas
- Cuando OpenAI comenzó a soportar el mismo protocolo en ChatGPT hace unos meses, MCP empezó a consolidarse como un estándar adoptado en muchos lugares
- MCP también fue incluido en Windows, lo que muestra el alcance de su expansión
- El punto importante no es tanto el grado de completitud de la especificación, sino el hecho de que varios actores adoptaron rápidamente la misma interfaz
- MCP se parece más a una especificación flexible, pero al estar abierto y funcionar, se parece a la forma en que tuvo éxito la web
Lo que originalmente significaba Web 2.0
- Web 2.0 no era un término para referirse a sitios cerrados y propietarios como Facebook
- En el centro de la comunidad inicial de Web 2.0 estaba la idea de que múltiples sitios ofrecieran APIs abiertas, permitiendo a desarrolladores y usuarios conectar personas y datos
- Flickr, Del.icio.us y Upcoming fueron sitios representativos de una época que abrió camino con funciones como etiquetas y compartición social
- Plataformas como LiveJournal y Movable Type también influyeron en el trabajo de estándares abiertos alrededor de APIs y protocolos
- Los valores compartidos en ese momento eran relativamente claros
- Construir herramientas, tecnologías y plataformas sobre datos abiertos y protocolos abiertos
- Que los usuarios tuvieran el control
- Que los desarrolladores interactuaran con sistemas mediante herramientas consistentes e interoperables
La interoperabilidad que las plataformas cerradas cortaron
- Durante una generación, se volvió difícil para los desarrolladores dar por hecho la interoperabilidad entre apps y plataformas
- También surgieron críticas de que grandes firmas de VC y líderes de la industria tecnológica pusieron fin a la era de la apertura
- Las herramientas para analizar actividad en redes sociales vieron cómo sus productos y servicios orientados a usuarios quedaban interrumpidos cuando las grandes plataformas sociales cerraban sus APIs
- Plataformas como Facebook y Twitter rompieron para muchas personas la promesa de Web 2.0 de datos abiertos y tecnología interoperable
- Como resultado, se volvió cotidiano que los usuarios no pudieran manejar sus redes de la manera que quisieran
- No se pueden ver fotos de Instagram incrustadas dentro del timeline de Twitter
- Es difícil usar funciones como importar o exportar seguidores, que sí son posibles en el fediverso o en Bluesky
- Es difícil controlar tu red desde la app que prefieras
La posibilidad que MCP podría volver a abrir
- El ascenso de MCP, combinado con el auge de la IA entre programadores, genera la expectativa de que las plataformas puedan abrirse no solo a los LLM, sino también a diversos fines de programación
- Un punto clave es que otras plataformas adoptaron tal cual una especificación creada por Anthropic
- Cuando una empresa adopta fielmente en segundo lugar el protocolo de otra, todo el ecosistema puede funcionar más fácilmente de la misma manera
- En cambio, copiar, extender y luego terminar eliminando un protocolo puede perjudicar al ecosistema
- Cuando existe una adopción de buena fe de una misma interfaz, aumenta el margen para que múltiples herramientas y plataformas funcionen juntas
La dificultad de seguir un estándar tal cual
- Soportar un estándar tal cual es más difícil de lo que parece
- Incluso al lanzar un producto de caché semántica para plataformas de IA, no fue fácil convencer a los desarrolladores de usar tal cual la API general de ChatGPT
- A los desarrolladores les resulta fácil pensar que pueden “mejorarlo”, pero en el momento en que se apartan del estándar, en realidad puede empeorar
- Incluso una mala especificación con muchas inconsistencias puede ser más valiosa si todos la implementan de la misma manera
- HTML también era una especificación incompleta a la que le faltaban muchas cosas, y aun así la web se construyó sobre ella
- Todo internet también está apoyado sobre varias especificaciones imperfectas
Exigir cumplimiento de estándares y transparencia
- Una nueva generación de desarrolladores está experimentando la creatividad y las posibilidades que surgen cuando las herramientas y plataformas que les gustan usan los mismos protocolos y formatos
- Corrientes como RSS, el podcasting, OpenID, OAuth y OpenSocial llevaron en algunos casos más adelante a resultados como el fediverso y ActivityPub
- Desarrolladores, programadores, entusiastas de la tecnología y usuarios comunes también pueden exigir a las plataformas el derecho de controlar su experiencia mediante código
- Cuando se accede a través de estándares abiertos como MCP, también hay que exigir transparencia sobre lo que las plataformas realmente hacen
- MCP es flexible, pero deja varios riesgos abiertos
- No es transparente cómo las plataformas manejan los datos de los usuarios
- Es difícil saber qué acciones pueden producirse en una interacción a través de MCP
- Los riesgos de seguridad son muy grandes
- El protocolo no aborda suficientemente estas preocupaciones
Los límites y las expectativas de la apertura estilo Web 2.0
- MCP no es una solución universal que arregle todos los problemas del ecosistema de desarrolladores
- Tampoco corrige la exageración ni las distorsiones del debate alrededor de la IA
- Aun así, existe la posibilidad de que desarrolladores jóvenes que no vivieron la etapa anterior de Web 2.0 intenten, a partir de MCP, acercar la web de nuevo a su arquitectura original
- La web no fue concebida como una estructura propietaria ni controlada por unas pocas personas de unas cuantas grandes corporaciones
- La web debía ser programable mediante especificaciones rústicas que todos adoptaban apresuradamente, y esa diversión hackeable existía desde antes de que la web tuviera número de versión
1 comentarios
Opiniones de Hacker News
Lo que mucha gente pasa por alto de MCP es que encaja bien con el software empresarial.
Los LLM son traductores de propósito general, así que son adecuados como pegamento para conectar sistemas aislados que serían extremadamente difíciles de unir sin alguna capa intermedia más o menos flexible.
Por eso el sector B2B SaaS está lanzando servidores MCP, y por eso internamente se debate cómo rediseñar las API y sus restricciones para ajustarlas a los nuevos patrones de uso.
El protocolo no está “listo para la empresa” según varias definiciones, pero, como dice el autor, eso no es tan importante. Si miramos la historia de los estándares, incluso cosas desordenadas y “malas” se adoptan ampliamente cuando encajan con las personas correctas en el momento correcto.
Hay menos discusiones sobre si cambiar un campo de un objeto de usuario es un PUT que reemplaza el objeto de usuario original o un POST. He perdido bastante tiempo con los verbos de REST.
Tampoco hace falta que un LLM entienda la semántica REST de una API. Puede mirar los métodos RPC disponibles y hacer una llamada que parezca funcionar. Creo que el punto central es realmente así de simple.
No es como si los endpoints negociaran entre sí un esquema que permita consultas baratas en el futuro.
Solo con eso ya se pueden habilitar funciones como el autodescubrimiento.
Cualquier lugar que vaya a ofrecer MCP, de todos modos, también ofrecerá una API decente.
Qué empresa no querría exprimir la máxima productividad de sus empleados durante el horario laboral.
La parte de “comparado con la época en que viejos gruñones de Unix escribían las especificaciones” me parece una de las varias razones por las que fracasó la web semántica. Y no contradice la idea del autor de que “lo peor es mejor”.
Creo que la gente se obsesionó demasiado con la eXtensible de XML y se acumuló cierto cansancio. XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS... llegó a ser demasiado.
Lo que el mundo necesitaba entonces era un formato de intercambio simple, y JSON encajó con esa necesidad, mientras que el lado de XML era casi arquitectura aeroespacial aplicada a formatos de datos.
Pero también creo que ahora le llegó el momento a XML. En prompts de sistema filtrados de lugares como Anthropic se ve XML con frecuencia. Los LLM parecen manejar bastante bien los formatos de texto estructurado, especialmente Markdown y XML.
Dicho eso, creo que MCP es el modelo equivocado. En vez de indicar al modelo que “tire” del contexto directamente, creo que nosotros deberíamos “empujar” el contexto hacia el modelo.
Tenía cuatro etiquetas de macro (
#=,#&,#?,#!) que se reemplazaban a sí mismas por el resultado de la expansión de macro, respectivamente como asignación, sustitución, ramificación condicional tipocondy llamada a función definida por el usuario, y terminé dándome cuenta de que estaba recreando XSLT.Lo que realmente quería era XPath. Es una forma de describir cómo recorrer un grafo hacia adelante y hacia atrás por varios ejes, y en realidad es una especificación excelente.
Luego encontré BaseX https://basex.org/, que permite importar documentos XML arbitrarios como una base de datos consultable y consultarlos con XPath o XQuery.
Para crear una interfaz confiable de lenguaje natural sobre datasets, sin alucinaciones, lo que mejor se ve es pasar el esquema XML al prompt de sistema y hacer que el modelo escriba las consultas que obtienen los datos.
Si ya supiera de antemano la información, probablemente habría resuelto el problema yo mismo.
El valor que se obtiene de MCP parece más bien “no me hagas aprender a conectar 15 fuentes; ejecuta alguna consulta por mí”.
Nadie™ le está dando a un LLM XML correcto que empiece con una declaración XML, ni usando namespaces, XSLT, XML Schema ni nada parecido.
Es más bien una colección arbitraria de etiquetas estilo SGML.
XML es una especificación grande, no solo corchetes angulares, e intenta cubrir todos los casos y manejar correctamente la seguridad y la codificación de caracteres.
Por eso la “edición de texto plano” no es muy intuitiva. Si escribes algo como este párrafo, puede que se parsee en modo de compatibilidad, pero quizá no sea válido.
Como formato de intercambio, o como formato que se carga en aplicaciones hechas para él, tiene más posibilidades, y los LLM seguramente no tendrán problemas para entenderlo, así que eso está bien.
Muchos de los problemas del pasado vinieron de programadores con poco tiempo y ganas de meter funcionalidades rápido, que blandían una especificación fuertemente estructurada como un garrote. “¿XML? Lo hago con regex”. Si tres programas distintos y tres autores distintos repiten eso, se arma un desastre.
Personalmente, el formato que en la práctica más se acercaba a lo que quería era BBCode. Es excelente como formato fuente para muchas cosas. Básicamente sigue siendo de la familia de los corchetes angulares, pero tiene la estructura y flexibilidad suficientes para servir como sintaxis de frontend de propósito general.
Las implementaciones iniciales eran “lo hago con regex”, pero tras décadas de prueba en producción, hoy también hay parsers más elegantes.
Pienso lo contrario de la frase: “El auge de MCP da esperanza de que, a medida que la IA gana popularidad entre los programadores, los LLM puedan abrir otras plataformas para que sean programables con cualquier propósito, y no solo para que ellos las controlen”.
MCP está destinado a fracasar por la misma razón por la que fracasó la web semántica: si algo no está encerrado, nadie gana dinero con eso.
Me pregunto cuántas partes de que la IA busque en la web por nosotros —perdón, de lo que llaman “deep-research”— podrían haberse resuelto de una mejor manera.
Los restaurantes podrían haber publicado sus menús en formato de metadatos y cualquiera podría haber encontrado los tacos más baratos de Texas con un script de Python, pero la realidad es que con una mano se encierra artificialmente la información detrás de barreras y con la otra se construye IA, incluidos centros de datos, para rodearlas. Visto a nivel macro, es simplemente una estupidez.
La ola anterior de agentes murió porque al final todos se dieron cuenta de que no se podía confiar en código propio ejecutándose en una máquina donde todo era negociable. Fue lo de Java en los 90.
Fundamentalmente, entre agentes que interactúan hay un problema de asimetría de información diseñado intencionalmente. Si se elimina, una gran parte de la sociedad dejaría de funcionar.
Por más recursos que le pongas al problema, alguien encontrará la forma de agotarlos por una ganancia minúscula.
MCP solo empeorará el problema cuando los agentes de IA se abalancen como una plaga de langostas sobre los servidores MCP públicos.
La opción estable parece ser una tarificación RPC por llamada. Al menos la entidad que opere el modelo o el agente actuaría como cámara de compensación de pagos, así que tiene más posibilidades que las API de Web 2.0.
Probablemente la forma de cobro más plausible sea incluir estos costos en los planes de suscripción. Parece la mejor manera de alinear incentivos.
Para empezar, quien le puso el nombre HATEOAS prácticamente preparó el terreno para que fracasara.
Si publicar datos en un formato estándar tuviera un valor “fácil”, los endpoints interoperables se habrían adoptado mucho más.
Por ejemplo, usando schema.org u ontologías comunes generales. Pero la realidad es que abundan los formatos a medida que cada vez requieren algún SDK mágico especial.
Exigirles a los restaurantes que publiquen sus menús en formato de metadatos es la barrera artificial.
Ahí está la belleza de las nuevas herramientas de procesamiento de lenguaje natural. El dueño del restaurante no necesita aprender JSON ni comprar un paquete de software que genere JSON.
Podemos usar los datos tal como están. El costo de crear herramientas útiles se acerca a cero.
Serán imprecisas, pero así es el lenguaje humano.
Me dan pena quienes creen que, porque existe MCP, podrán acceder a cualquier cosa.
Esas cosas estarán escondidas detrás de decenas de capas de verificación de pago y autenticación. Por supuesto, también habrá IP en lista de permitidos, y obviamente será IPv4.
Lo único que verán probablemente será
ERR 402;.Lo que más me preocupa de MCP no es que el protocolo esté pésimamente hecho, sino que arreglarlo y mejorarlo dependa solo de equipos internos de Anthropic y OpenAI.
Las personas que hacen el protocolo no parecen ingenieros que también lo implementen de verdad.
Me recuerda vagamente al duopolio Visa-Mastercard.
https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...
Ahora que los LLM pueden leer documentación de API y adaptarse, ¿no será menos necesario que antes seguir una API estándar?
Para mí, la ventaja importante es que se genera la expectativa de que un sitio “tiene” una API, independientemente de si sigue o no la especificación MCP.
Incluso con buena documentación, un LLM puede generar código incorrecto para interactuar con la API. Si corriges el código generado y haces que el LLM lo llame para interactuar con la API, de todos modos ya estás en camino hacia una capa intermedia. En la práctica estás creando un servidor “tipo MCP”.
También hay problemas de seguridad o de asignación de recursos al dar acceso directo a una API a un LLM. El LLM tiene un conocimiento limitado de cuándo se llamó por última vez a la API. Puede llamarla con demasiada frecuencia y, si el costo por llamada es alto, terminarás con una factura de infraestructura inesperada.
Además de eso, hay muchos otros posibles puntos de dolor que se resuelven poniendo algo en medio.
Personas razonables pueden discrepar sobre si ese “algo” debe ser MCP. Por ahora parece funcionar lo suficientemente bien para que la gente haga lo que necesita.
Ahora podemos crear la web semántica. Solo hace falta crear un pequeño protocolo para que las organizaciones compartan sus DDL SQL
CREATE TABLEcomo archivos estáticos que una app MCP pueda leer. Bastaría como extensión opcional de MCP.Entonces, usando herramientas ya existentes que conectan llamadas de funciones de IA/LLM con SQL, se podrían entender y consultar los datos; eso sería la web semántica.
Este enfoque completa el eslabón perdido que siempre bloqueó a la web semántica: el problema de que las empresas no tenían incentivos para usar “tipos de datos” estándar en lugar de tipos de datos propietarios.
Si aparece MCPQ, es decir, MCP con consultas, de pronto las organizaciones tendrán motivos para colaborar en la capa de estructura de datos.
Resulta que la “web semántica” siempre fue la web sintáctica, y tal vez esta vez sea la verdadera.
Me pregunto cuánto tardará alguien en crear un servidor MCP que controle algo como una cucaracha
Material de referencia:
https://www.technologynetworks.com/informatics/news/robo-roa...
https://www.sciencealert.com/scientists-turned-cockroaches-i...
Y hay muchos otros ejemplos que se remontan a más de 10 años atrás
Me da bastante risa la expresión “cuando las especificaciones las escribían viejos señores quisquillosos de Unix”
Es interesante que esta generación imagine a los “viejos señores de Unix” como gente quisquillosa. Unix fue, en realidad, la rebelión definitiva de moverse rápido y romper cosas contra la escuela del MIT
Parece que hay cosas que no cambian :-)