La llegada de la Web 2.0 2.0: MCP

• Model Context Protocol (MCP) se está adoptando rápidamente y está emergiendo como un nuevo estándar abierto
• El valor central de MCP no está en la perfección, sino en la apertura y la interoperabilidad
• El verdadero significado de la Web 2.0 no son las plataformas cerradas, sino las API abiertas y el intercambio de datos
• Está surgiendo una tendencia de regreso desde la era del cierre hacia el valor de la web abierta
• La adopción de MCP podría llevar a que los desarrolladores exijan aún más control sobre las plataformas y transparencia

---

MCP: la aparición de una nueva web abierta

En los últimos meses, el interés por Model Context Protocol (MCP) ha explotado entre los desarrolladores. El punto de partida fue que Anthropic lo diseñó en 2023 para que su propio sistema LLM (Claude) pudiera interactuar con distintas apps. Después, OpenAI incorporó soporte para el mismo protocolo en ChatGPT, y así se consolidó rápidamente como estándar. Ahora incluso se está adoptando en Windows, expandiéndose hacia plataformas principales.

Lo interesante es que el atractivo de MCP no está tanto en su claridad o grado de madurez, sino en su facilidad de uso y velocidad. A diferencia de los estándares tradicionales diseñados con rigor, MCP es una especificación algo ambigua y definida con flexibilidad, pero su gran fortaleza es que en la práctica funciona bien. Sobre todo, es importante que sea un protocolo abierto que cualquiera puede utilizar.

El verdadero significado de la web abierta

En el mundo real de la web, el verdadero avance ocurre cuando estándares imperfectos y algo limitados se adoptan rápidamente. Ese tipo de dinámica hizo posibles innovaciones como "Escúchalo en cualquier lugar donde oigas podcasts".

El espíritu de la Web 2.0 apuntaba a un ecosistema abierto: API abiertas, intercambio de datos y mayor control para usuarios y desarrolladores. Hay que tener presente que plataformas cerradas como Facebook fueron las que acabaron destruyendo la Web 2.0. En el pasado, Flickr, del.icio.us, Upcoming y otros impulsaron una cultura centrada en compartir y conectar, y en plataformas como LiveJournal hubo un debate muy activo sobre estándares abiertos para API y protocolos.

El regreso de lo abierto

Tras una generación, estamos otra vez en un momento en el que crecen las expectativas sobre la interoperabilidad. En el pasado se repitió una y otra vez la experiencia de ver cómo las grandes tecnológicas bloqueaban API y hacían desaparecer servicios con sus políticas cerradas. Por ejemplo, una herramienta de análisis de datos de redes sociales construida por el autor terminó descontinuándose por el bloqueo de API por parte de la plataforma. Ese tipo de políticas derrumbó la visión de datos abiertos y compatibilidad propia de la Web 2.0. Como consecuencia, se volvieron cotidianos problemas como la imposibilidad de embeber contenido o las trabas para mover datos entre servicios.

Sin embargo, con la llegada de MCP, se espera que la IA actúe como detonante de un resurgimiento de la programabilidad y la apertura. Que varias plataformas adopten el mismo protocolo puede habilitar un círculo virtuoso a nivel tecnológico.

Cuando una plataforma adopta el protocolo tal cual y respeta la estandarización, se generan cambios positivos para todo el ecosistema. Se subraya que el impulso de los desarrolladores por "hacerlo mejor que la especificación" puede, paradójicamente, perjudicar al ecosistema. También HTML, aunque no sea una especificación perfecta, terminó convirtiéndose en la base de la interoperabilidad masiva de internet.

La importancia de cumplir con los estándares

Una nueva generación de desarrolladores está experimentando de primera mano la fuerza de innovar sobre la base de protocolos y formatos comunes. Es muy probable que esa experiencia vuelva a derivar en una insistencia casi obsesiva por los estándares abiertos. Se recrea una atmósfera parecida a la de la época en que formatos abiertos como RSS, Podcast, OpenID, OAuth y OpenSocial realmente empoderaban a los usuarios.

Este ya no es un momento exclusivo de las grandes empresas: es un momento en el que las comunidades de desarrolladores y usuarios pueden ejercer por sí mismas su capacidad de exigir. Todos deberían poder pedir a las plataformas control sobre la experiencia y transparencia, y cuando se adopten estándares abiertos como MCP, esa adopción debe ir necesariamente acompañada de transparencia sobre el funcionamiento interno de la plataforma y el uso de los datos. MCP es abierto, pero todavía presenta carencias en aspectos como su funcionamiento interno y los temas de seguridad, por lo que hacen falta mejoras posteriores.

La posible reactivación del espíritu de la Web 2.0

MCP no es una solución mágica que resolverá todos los problemas, pero parece poder convertirse en un detonante para revivir el ecosistema abierto de la era de la Web 2.0. Siguen presentes limitaciones como la exageración en torno a la IA o la falta de crítica en muchas discusiones.

Aun así, entre los desarrolladores jóvenes se está revalorizando la idea de una web programable y de salir de la lógica cerrada. La web no era propiedad exclusiva de unas cuantas grandes empresas, sino un espacio abierto que cualquiera podía usar a su manera, y se plantea la posibilidad de que MCP vuelva a traer esa filosofía.

[GN⁺]

Comentarios en Hacker News

• A muchos se les pasa por alto que la clave de MCP es que encaja muy bien con el software empresarial; un LLM puede funcionar como una especie de traductor universal y como una capa intermedia flexible que conecta sistemas difíciles de integrar entre sí. De hecho, en la industria de B2B SaaS ya se está adoptando con fuerza el uso de servidores MCP, y dentro de las empresas también hay cada vez más discusión sobre ajustar restricciones o estructuras según los patrones de uso de las API. Incluso si el protocolo no es “enterprise ready” en muchos sentidos, eso no parece tan importante; en la historia de los estándares ha sido común que especificaciones poco refinadas o “medio improvisadas” igual terminen adoptándose si responden a una necesidad real del mercado
  • Entiendo MCP como algo parecido a un RPC que funciona sobre conexiones largas, por lo general basado en WebSocket. Personalmente, RPC me parece más fácil por dos razones: primero, evita discusiones innecesarias del tipo si en un endpoint REST hay que reemplazar todo con POST o modificar solo ciertos campos con PUT; segundo, el LLM no necesita entender la terminología ni la semántica de REST, solo ver los métodos RPC y llamarlos de inmediato. En resumen, esas dos cosas son fortalezas muy grandes
  • Desde la perspectiva empresarial, vale la pena señalar que MCP es un excelente modelo de ingresos. Cada solicitud de datos queda vinculada directamente a una ejecución pagada de LLM. Por otro lado, deja cierta sensación de desperdicio que con MCP no exista ninguna optimización como negociación de esquemas que abarate las consultas futuras
  • Ya existen REST y OpenAPI, y con eso ya se soportan funciones como el self-discovery automático. También creo que las empresas que ofrezcan MCP de todos modos van a terminar ofreciendo buenas API
  • Esta parte me hace mucho sentido: en las grandes empresas hay muchos ingenieros que entre 9 y 5 hacen trabajo excelente y, al salir, ni siquiera quieren pensar en la compañía. Si ese es el caso, para una empresa la conclusión lógica es maximizar la productividad de sus empleados dentro del horario laboral
• Me da curiosidad cuánto falta para que aparezca un experimento donde un servidor MCP controle criaturas tipo cucaracha; en la práctica ya hubo muchos casos durante más de diez años, como los experimentos de robo-roach y cucarachas cíborg
• Antes, los desarrolladores de Unix redactaban especificaciones con mucho rigor, pero los tiempos cambiaron, y quisiera plantear que ese exceso de rigidez y el cansancio frente a lo “eXtensible” fueron una de las razones del fracaso de las arquitecturas basadas en XML. En ese momento había arquitecturas demasiado complejas, con XSL, XHTML, XSD, WSDL, RDF, RSS y más, y al final por eso formatos simples como JSON ganaron popularidad. Aun así, últimamente también he visto una tendencia de mayor uso de XML, especialmente en system prompts de sistemas LLM como Anthropic, donde se usa bastante texto estructurado como XML o Markdown. Pero creo que el modelo de MCP está mal planteado: en vez de pedirle al modelo que “jale” información, es mejor un enfoque de “empujarla”, es decir, darle contexto por adelantado
  • Algo interesante es que, al crear hace poco un lenguaje de expansión de macros basado en JSON, me di cuenta de que en realidad estaba reinventando XSLT o XPath, y eso me hizo apreciar mucho la especificación de XPath por lo buena que es para explorar grafos. Con herramientas como BaseX puedes cargar XML arbitrario en una base de datos y consultarlo con XPATH/XQUERY, lo cual resulta muy útil. Si la idea es construir una interfaz de datos sólida para evitar que el LLM diga tonterías, me parece que la mejor solución es meter un esquema XML en el system prompt y hacer que genere consultas de datos
  • Tengo dudas sobre hasta qué punto ese “modelo de empujar contexto por adelantado” puede resolver problemas reales. Si el usuario ya supiera la información de antemano, simplemente resolvería el problema directamente, y gran parte de la demanda de MCP viene de cosas como “haz la consulta sin obligarme a aprender cómo conectar 15 fuentes distintas”
  • Los LLM procesan bien XML en forma de tags, pero en la práctica casi nadie usa verdaderos bloques XML completos, con <?xml version="1.0" encoding="UTF-8"?>, namespaces, esquemas y demás; lo que suele usarse es más bien una colección de tags estilo SGML
  • Quiero enfatizar que la verdadera razón por la que fracasó la web semántica fue algo mucho más práctico: nunca logró integrarse con la inserción de anuncios ni con un modelo de negocio viable
  • Soy crítico del enfoque de “empujar contexto”: la capacidad de contexto de los LLM (context window) es muy limitada, así que lo óptimo es entregar solo la información estrictamente necesaria. Si cada modelo pudiera elegir por sí mismo y hacer pull únicamente del contexto que necesita, habría más posibilidades de superar ese límite
• MCP parece dar esperanza de que, gracias a la popularidad de la IA, varias plataformas se vuelvan programables para cualquier propósito, pero creo que está destinado al fracaso, porque la web semántica también fracasó por no construir una estructura de ingresos. Lo mismo pasa con las funciones de “research” donde la IA profundiza en la web por nosotros. Por ejemplo, sería posible publicar menús de restaurantes como metadatos y automatizar búsquedas como “encontrar el taco más barato de Texas”, pero en la realidad lo que vemos es una competencia de infraestructura entre el bloqueo de datos y los crawlers de IA que tratan de saltarse esas barreras. Viéndolo en grande, la conclusión es que el sistema actual es ineficiente
  • Al final, MCP no sería más que una versión evolucionada de robots.txt: en esencia es un modelo de “si describes bien mis recursos, los aprovecharé”. Ya en los 90 hubo sistemas de agentes basados en Java que fracasaron por la asimetría de información entre agentes, y preocupa que si se elimina esa limitación de diseño quizá toda la maquinaria social y de negocios deje de funcionar
  • Antes incluso del problema de monetización, con las API abiertas pasa algo muy práctico: si no pones recursos prácticamente ilimitados, la ola de bots de solicitud de agentes de IA termina agotando los recursos y te lleva a la quiebra. A largo plazo, creo que un modelo RPC de pay-per-call será una alternativa más estable. Lo más probable es que los operadores de modelos o agentes terminen actuando como una cámara de compensación de pagos, incorporando ese costo dentro de sus suscripciones u otros cobros
  • El ideal arquitectónico REST de HATEOAS estuvo muy de moda a inicios de los 2010, pero fuera de herramientas de automatización como swagger yaml, desapareció sin una expansión real. Hasta su terminología era demasiado difícil y eso mismo ayudó a condenarlo al fracaso
  • No estoy de acuerdo con ver el texto legible por humanos como una barrera artificial. De hecho, pedirle a un restaurante que adquiera la capacidad de producir JSON o que implemente software para eso sí es una barrera artificial real. Gracias a las herramientas de NLP, ya es posible aprovechar los datos existentes tal como están, reduciendo el costo de desarrollo casi a cero. Aunque haya cierta imprecisión lingüística, eso es parte natural del lenguaje humano y no me parece un problema grave
  • Lo menciono con cuidado en medio de esta crítica a la web semántica, pero si un dueño de restaurante realmente quisiera, podría publicar metadatos en cualquier momento y eso serviría para conectar fácilmente compradores y vendedores. Por ejemplo, con plugins de WordPress ya existe soporte para metadatos como schema.org/Restaurant, Menu, MenuItem y Offer. Al final, sospecho que la barrera principal son mecanismos de gatekeeping como Cloudflare, que en la práctica sí bloquean ideas de automatización en Python
• Como los LLM pueden leer documentación de API y adaptarse automáticamente, pienso que cumplir con estándares formales de API ya no es tan indispensable como antes. Incluso independientemente de si se adopta o no la especificación MCP, el simple hecho de esperar que cada sitio “ofrezca una API” ya representa un cambio grande
  • En entornos reales, la documentación de API puede ser deficiente, así que un LLM puede generar código o llamadas incorrectas. Si el usuario las corrige y se las vuelve a pasar al LLM, eso termina dando como resultado una capa intermedia, algo tipo servidor MCP. Además, dar acceso directo del LLM a una API también implica riesgos en seguridad y gestión de recursos, como facturas descontroladas por llamadas excesivas. Hay varios pain points adicionales, y algunos se resuelven precisamente con una interfaz intermedia como MCP. Otra cosa es si ese intermediario necesariamente tiene que ser MCP, pero hoy por hoy sí parece una solución bastante práctica
• Lo que más me preocupa de MCP no es tanto que el protocolo esté verde, sino que el poder de mejorarlo o corregirlo esté concentrado solo en equipos dentro de empresas como Anthropic u OpenAI. También da cierta desconfianza que la especificación parezca quedarse en una etapa de brainstorming, más que estar guiada por quienes realmente desarrollan y operan sistemas. Se siente un poco como la sombra de un duopolio tipo Visa-Mastercard
  • Existe también el caso de que Microsoft se sumó al steering committee
• La “web semántica” en realidad era poco más que una estructura gramatical, así que existe la expectativa de que MCP sí pueda tener viabilidad práctica de verdad
• Hay una percepción de que “los grandes desarrolladores Unix de la vieja escuela eran excesivamente quisquillosos”, pero irónicamente Unix también fue la cuna de la cultura de “probar rápido y romper cosas”. Cambian las generaciones, pero la esencia no cambia
• Existe una preocupación muy real de que MCP pueda ser explotado, igual que el SEO en Google, para expandir publicidad y spam dirigidos a la IA
• Creo que hay que tener cuidado con la ilusión de que MCP hará que todos puedan acceder fácilmente a toda clase de datos. En realidad, todo seguirá atado a varias capas de autenticación de pago, IP permitidas en listas blancas y otros mecanismos de seguridad, y para el usuario final lo más probable es que la experiencia real termine siendo simplemente recibir un error “ERR 402”