MCP: un sistema de plugins universal (por accidente)

• USB-C no vale solo para cargar o transferir archivos, sino por su universalidad para expandirse a usos muy diversos
• MCP (Model Context Protocol) fue diseñado originalmente para asistentes de IA, pero en la práctica puede convertirse en un sistema de plugins universal que conecta cualquier fuente de datos y herramienta
• Como en el caso de NFT Base64, un protocolo puede expandirse más allá de su propósito original para almacenar y aprovechar directamente datos del mundo real
• Cuantos más servidores MCP existan, más fácil será para cada app incorporar funciones diversas sin integraciones separadas
• Al igual que USB-C, MCP puede convertirse en un "espacio de posibilidades" donde se puede conectar cualquier cosa, sirviendo de base para innovaciones inesperadas

---

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

USB-C y su universalidad inesperada

• Todo el mundo pensaba que USB-C era solo para cargar o transferir archivos, pero gracias a su estructura puede extenderse a muchos usos
• El autor muestra las posibilidades infinitas de USB-C con el caso de su amigo Rex, que conectó una tostadora a un monitor y logró que la tostadora tuviera salida HDMI
• Esto es posible porque USB-C es una estructura donde, sin preocuparse demasiado por las especificaciones de energía y datos, si el conector encaja se puede conectar prácticamente cualquier cosa

El principio del encendedor de auto

• El encendedor de auto fue creado originalmente para prender cigarrillos, pero hoy se usa como un puerto de energía universal para muchas cosas
• Como el encendedor, un protocolo no limita la elección del usuario y permite usos diversos
• MCP tiene una capacidad de expansión similar

Redescubriendo MCP: por accidente, un sistema de plugins universal

• Normalmente se entiende que MCP (Model Context Protocol) sirve para que asistentes de IA, como Claude, puedan usar datos
• La documentación oficial también dice que "conecta de forma estandarizada modelos de IA con múltiples fuentes de datos y herramientas"
• Pero si quitamos el componente de IA, MCP se convierte en una forma de conectar "cualquier cosa" con distintas fuentes de datos y herramientas
• En otras palabras, termina siendo un protocolo de conexión universal independientemente de su propósito original

La revelación de NFT Base64

• Los NFT originalmente servían para referenciar imágenes, pero en algún momento la referencia misma pasó a ser el dato
• Al cambiar la intención original del protocolo, la ficha de biblioteca terminó haciendo el trabajo del libro real
• Así, se transformó en una herramienta para manejar directamente datos reales mucho más amplia que lo que se había pensado al inicio

Un efecto de red que nadie esperaba

• A medida que aumentan los servidores MCP para IA, se produce el efecto de que cualquier app puede adquirir nuevas funciones sin desarrollo adicional
• Por ejemplo, si alguien crea un servidor MCP de Spotify, una app de ejercicio podría generar playlists automáticamente a través de MCP
• Se genera un efecto de red en el que desarrolladores y apps que ni siquiera se conocen terminan conectándose de forma natural y todos salen ganando
• Cada servidor MCP puede reutilizarse como un plugin universal
• Nadie lo planeó, pero por accidente se está formando un ecosistema universal de plugins

El significado de USB-C y la filosofía de MCP

• A menudo se compara MCP con el USB-C de la IA, pero lo especial de USB-C no es que sea solo un puerto, sino que es un espacio de posibilidades donde se puede conectar cualquier cosa
• Así como USB-C puede aceptar energía, datos, video y otras funciones todavía desconocidas, MCP no es solo "para IA", sino un "hueco bien diseñado para funciones" al que cualquiera puede conectar cualquier capacidad

La parte en la que les cuento que estoy construyendo algo

• El autor está desarrollando una app de gestión de tareas llamada APM (Actions Per Minute)
• APM funciona como un sistema de plugins usando exclusivamente servidores MCP
• Cada vez que el usuario quiera agregar una función, solo tendrá que conectar un servidor MCP (por ejemplo: corrector ortográfico, pedido automático de café, reacciones de personajes de juegos, etc.)
• Esto le da a la app una estructura capaz de transformarse de manera flexible en muchas formas distintas

El principio del protocolo de la tostadora

• Todos los grandes protocolos terminan creando innovación cuando se usan para cosas inesperadas, distintas a su intención original
  • HTTP: de artículos académicos → infraestructura de la civilización
  • Bluetooth: de manos libres → desbloqueo de puertas de entrada, etc.
  • USB: de dispositivos de entrada → carga de ventiladores portátiles, etc.
• MCP también nació para pasar contexto a la IA, pero en esencia es un protocolo que conecta todo con todo
• El autor enfatiza que es la base de un ecosistema de plugins capaz de producir innovaciones impredecibles
• Aunque nadie lo planeó, es un enfoque perfecto para una era en la que una tostadora puede conectarse por HDMI a un monitor

Cierre

• PD: si alguien crea una computadora que saque olor a pan recién hecho mediante un servidor MCP, por favor que le escriba
• PPD: ya está disponible el acceso anticipado de APM y se alientan los intentos ingeniosos y los experimentos creativos
• (En algún lugar, un protocolo se está usando exactamente para lo que fue diseñado. Eso resulta muy sospechoso)

[a1eng0]

Las respuestas del servidor MCP suelen ser lenguaje natural, sin un schema definido.

Va a ser difícil procesar programáticamente estas respuestas en lenguaje natural sin un LLM.

[winterjung]

Como referencia, en la especificación de mcp del 2025-06-18 se añadió recientemente structured tool output, así que ahora ya es posible describir el schema de respuesta. Como mencionaste, la mayoría de las herramientas mcp implementadas hasta ahora probablemente sean unstructured, pero parece que vale la pena tener expectativas para las herramientas mcp de aquí en adelante.

[a1eng0]

Qué gusto verte por aquí otra vez, Gyeoul jaja

No había podido seguir la especificación del 250618. ¡Gracias!

[GN⁺]

Opiniones de Hacker News

• Siento que este artículo y el protocolo MCP me gustan mucho. Pero cuando veo MCP, de algún modo me recuerda a los microservicios y a SOA. Me preocupa que no estemos repitiendo la pesadilla de crear nuevos puntos de falla. O, por otro lado, también tengo la esperanza de que, gracias a la adopción de agentes, mejorar la confiabilidad pueda darse de una forma más natural

• Coincido con la idea del artículo y me parece muy interesante que el autor use MCP de una forma un poco fuera de lo convencional. El verdadero punto de esta línea de pensamiento no es simplemente la aparición de un protocolo que permita hacer cosas nuevas que antes no existían. De hecho, como dicen otros comentarios, MCP en sí no es una idea especialmente nueva ni interesante. Lo realmente interesante es que, gracias al boom de los agentes de IA, la interoperabilidad está recibiendo atención y el problema del vendor lock-in empieza a tratarse como algo pasado de moda. No sé cuánto durará esto, pero por ahora me deja una buena sensación

  • Esto me recuerda a cuando apareció Winsock. Hubo una época en que todo lo relacionado con redes en Windows usaba interfaces privadas distintas y desordenadas. Luego hubo un momento en que varios vendors se sentaron juntos y decidieron crear un estándar común que beneficiara a todos. Véase Wikipedia de Winsock
  • El punto no es solo que la interoperabilidad se haya puesto de moda o que conectarse sea fácil. La verdadera innovación es que los propios LLM aprendieron a usar herramientas. Si yo solo construyo el backend, el frontend deja de ser mi problema y la IA lo resuelve por su cuenta. Claude y Gemini también son capaces de usar herramientas por sí mismos si solo se les da el objetivo. Antes siempre había que definir de forma explícita un procedimiento paso a paso para obtener el resultado deseado, pero ahora los LLM se adaptan mucho mejor a situaciones cambiantes que un programa fijo, y eso se siente como un cambio enorme
  • Se siente un entusiasmo excesivo. Pero creo que los agentes de IA sí crearon un incentivo claro para la interoperabilidad. Antes, que todos trabajaran lentamente dentro de sus propios sistemas garantizaba empleos estables, pero ahora la tendencia es conectar todo con todo. Es como si al CEO le saliera más barato ir él mismo por las pizzas del hackathon: los agentes dependen de la integración. Como alguien que estuvo directamente en la ola anterior de innovación de integraciones por API, siento que recién ahora el mundo se está poniendo al día. Ojalá este ambiente dure
  • No estoy del todo de acuerdo con la idea de que el boom de los agentes de IA esté impulsando la moda de la interoperabilidad y volviendo anticuado el vendor lock-in. Herramientas recientes y muy comentadas como Cursor usan MCP solo en una dirección, pero no sacan hacia afuera el historial de conversación ni el contexto. Me gusta Cursor, pero desde su fork no open source de VS Code, esa mentalidad de no devolver nada me parece negativa para la confianza de los desarrolladores. Al final, el lock-in sigue bastante firme
  • Irónicamente, las recientes restricciones de acceso a APIs se han intensificado precisamente por el tema del entrenamiento de datos para IA. En realidad, este tipo de bloqueo de APIs ya existía desde mucho antes, y también hay una visión escéptica según la cual esta nueva tendencia de apertura puede cerrarse de nuevo en cualquier momento si no logra sostener las expectativas infladas

• El autor pone muchas expectativas en la universalidad de MCP, pero sinceramente me pregunto en qué se diferencia realmente del concepto mismo de una API. ¿Cambiaría tanto el contenido del artículo si reemplazáramos MCP por REST? También hay similitudes con las APIs de sistemas operativos, POSIX o los pipes de Unix. Claro, MCP es mucho más simple y universal que todo eso. Pero quizá la verdadera solución no sea crear una nueva abstracción cada vez, sino hacer software simple y fiel a lo básico

  • MCP no es lo mismo que REST. Más bien, se siente como un protocolo que permite descubrir dinámicamente endpoints REST en tiempo de ejecución y que deja al usuario configurar qué endpoint REST usar. Por ejemplo, si una app va a reproducir una canción de Spotify, obviamente usa la API de Spotify. Si después quieres soportar canciones de Sonofm, en el enfoque tradicional hay que modificar el código, agregar condicionales, publicar una nueva versión, avisar a los usuarios de la actualización, etc. En cambio, MCP permite configurar esto en tiempo de ejecución, así que se siente mucho más extensible
  • La diferencia clave es que MCP exige introspección desde el principio. REST también tiene OpenAPI, pero eso fue un añadido posterior y además su adopción estándar es baja. En cambio, MCP exige que primero se publique la descripción, así que el nivel de accesibilidad es distinto
  • Desde mi punto de vista, lo único que realmente se siente nuevo en MCP es que obliga a proporcionar esquemas a nivel de protocolo. Claro, tener una estructura consistente de requests y responses también hace más fácil el manejo para librerías que envuelven tipado dinámico con tipado estático. En realidad, todo el mundo ya hacía algo parecido con APIs. Lo que no habíamos logrado era ponernos de acuerdo sobre la forma de ese envelope. Creo que está recibiendo atención porque exigir el esquema desde el inicio y permitir que los modelos de IA lo aprovechen de inmediato sí tiene valor
  • Una gran diferencia entre MCP y REST es la existencia de un comando integrado llamado list-tools. Una API REST puede listar recursos de muchas maneras, pero MCP ofrece una sola forma estandarizada
  • Otra gran diferencia es que MCP lleva incorporado en el propio protocolo un procedimiento de discovery. En REST no hay ningún elemento que le diga al cliente qué recursos existen o qué capacidades tiene la API

• Mucha gente dice que MCP es increíble, pero no he visto tantos casos de uso realmente impresionantes. Me da una sensación parecida a la moda del blockchain. Al final, MCP me parece una solución temporal hasta que la IA se vuelva más inteligente. En unos dos años, creo que en vez de MCP simplemente se les dará a las IAs la documentación de las herramientas o el OpenAPI tal cual, y ellas absorberán por sí mismas todo el contexto

  • Por ejemplo, dudo que simplemente darle la documentación de Ableton Live ayude a Claude a crear música por su cuenta
  • Por muy buenos que se vuelvan los modelos, al final su utilidad sigue siendo bastante limitada si no se les da acceso determinista a herramientas y a información sobre el estado del mundo. Y si además consideras el tema de seguridad, no puedes dejar que un modelo haga requests arbitrarios en producción sin control. Creo que el entusiasmo alrededor de MCP es un poco excesivo, pero el problema del que se habla aquí sí es realmente importante. Si este protocolo logra que los desarrolladores expongan sus funciones de forma clara mediante APIs, eso sí sería algo muy prometedor
  • La moda del blockchain y MCP son bastante diferentes. Yo también era escéptico al principio, pero cuando implementas aunque sea un poco un servidor MCP te das cuenta de que la experiencia es completamente distinta. Se vuelve posible mezclar IA conversacional/de voz y los LLM actuales con MCP y varias herramientas y funciones, conectadas a APIs y a datos/servicios privados, y eso da la sensación de entrar a una frontera totalmente nueva. No es 100% perfecto, pero para casi todos los casos de uso reales ya es suficientemente bueno, y parece que la forma misma de crear apps va a cambiar mucho
  • De hecho, yo quería saber qué actividades hicieron esta semana los legisladores de mi estado y no había una forma fácil de encontrar esa información, así que escuché que MCP junto con la API de congress.gov era una combinación atractiva y terminé creando un servidor MCP. Publiqué el código aquí. Ahora realmente lo uso muy bien para consultar en tiempo real los movimientos del Congreso de EE. UU.
  • Mientras la arquitectura de los modelos de IA siga evolucionando, creo que va a ser difícil que desaparezca fácilmente una capa intermedia de middleware como MCP

• Yo creo que aquí Microsoft está aplicando su estrategia de siempre de "Embrace, Expand, Extinguish". Con el argumento de la estabilidad y la seguridad del sistema, descubrir herramientas dinámicamente con agentes sin ningún control aumenta el riesgo de conflictos. Hay alternativas como PydanitcAI, pero al final Microsoft ya salió a empujar oficialmente MCP en Build 2025 y está marcando el ritmo de la industria a su manera. Anthropic publicó el estándar con herramientas débiles y sin gobernanza, así que Microsoft tiene un terreno fácil para ocupar. El siguiente paso sería que Microsoft convierta su propio registro en estándar de la industria y lo combine con comandos específicos de Windows. Al final, la imagen que se dibuja es la de Microsoft inclinando los criterios de “seguridad” a su favor para dejar fuera a los competidores

• ¿Y qué pasa si quitamos por completo el componente de IA? Me preocupa que, si se depende directamente de servidores MCP sin middleware de IA, se choque de inmediato con problemas de compatibilidad hacia atrás. Porque los servidores MCP asumen que quien los invoca es un algoritmo de IA, así que puede haber breaking changes en las herramientas o en los esquemas de entrada/salida en cualquier momento

• Yo también lo pensé de forma parecida, pero al final creo que la mayoría de los servidores MCP no son más que nuevos clientes para APIs ya existentes. Por ejemplo, el servidor MCP de Kagi solo llama a la API de Kagi. Entonces, ¿no sería mejor usar la API directamente? Además, el sistema va a terminar con tantos intérpretes de Python como servidores MCP haya corriendo, así que me pregunto si en el futuro aparecerá algún servicio de “hosting” que los junte y los puentee todos de una vez

  • Según entiendo, MCP básicamente equivale a agregarle a una API existente un endpoint más llamado /list-tools. Todos los clientes primero consultan /list-tools para obtener la lista de herramientas disponibles y después llaman a cada API correspondiente
  • Mi enfoque es este: si ya existe una API con especificación OpenAPI, ¿no bastaría con envolverla con FastMCP? De hecho, hice la prueba integrándola con Goose mientras manejaba requests de autenticación, y la conclusión fue que Goose al final solo necesita lanzar comandos curl a las rutas existentes de la API. Si la especificación OpenAPI está lo suficientemente bien hecha, puede que MCP no sea realmente necesario. Claro, si no existe una API previa, entonces sí parece que el propio servidor MCP termina evolucionando para implementar la lógica principal

• Hay muchas posturas escépticas en los comentarios, y me identifico con ellas. La semana pasada implementé yo mismo un servidor MCP y sinceramente me parece exagerado decir que está “bien diseñado”. Uno de los objetivos de MCP es “hacer que sea fácil de construir”, pero cuando lo haces en la práctica no resulta tan sencillo. Aun así, lo importante es que ahora mismo la atención de muchísimos desarrolladores está concentrada en una misma dirección. Con ese tipo de momentum, la velocidad para resolver problemas puede ser muy alta. Además, para que exista un ecosistema tiene que formarse una masa crítica alrededor de algo, y siento que ese punto de inflexión realmente está llegando ahora. Les deseo paciencia y suerte a todos

  • Si solo usas la librería de Python de MCP, de verdad es muy fácil. Solo le pones un decorador a una función y la herramienta queda lista de inmediato. Yo tampoco conocía para nada el protocolo MCP, pero con ese método me está funcionando bien. Claro, si tuvieras que implementar el protocolo directamente, quizá la historia sería distinta
  • Un servidor MCP solo necesita volver a exponer una “API pública o semipública existente”. Tiene sentido la idea de que debería poder implementarse con el mínimo posible de cambios a los endpoints originales
  • Ya ha habido intentos parecidos antes, pero al cabo de unos años las apps terminan bloqueando sus endpoints para que solo puedan acceder servidores específicos como chatgpt o claude. La interoperabilidad, en realidad, también es portabilidad para el usuario, y en la práctica muchas empresas tecnológicas prefieren el lock-in y el monopolio antes que la portabilidad

• Vale la pena subrayar que, a lo largo de la historia, bajar la barrera de entrada ha tenido un papel clave para la adopción y expansión de la tecnología. MCP va en esa misma línea, y no debería subestimarse. Incluso en nuestro equipo, una persona sin ningún background técnico pudo usar directamente un agente para automatizar tareas de compartición de archivos. Claro, antes eso solo era posible con cientos de lenguajes de programación, librerías y APIs, pero gracias a MCP llegamos a una era en la que incluso alguien no especializado puede resolverlo al instante sin preocuparse por eso. Tal vez no sea lo mejor en rendimiento ni la implementación óptima, pero el valor que trae esta nueva forma, con el nivel actual de recursos y tecnología, no tiene precedentes. Ese es el verdadero punto importante

  • Me parece exagerado eso de que una persona del equipo sin perfil técnico haya podido organizar por sí sola todo el tema del file sharing. Tal vez si hablamos de miles de archivos, pero por mi experiencia, en casi cualquier intento de ordenar un sistema de archivos compartidos cuesta incluso conseguir la cooperación de los departamentos implicados. Incluso a los responsables del trabajo no les gusta porque sienten que ni siquiera les corresponde. A veces hay que involucrar a ejecutivos de alto nivel para lograr convencerlos, o sentarse juntos durante una hora solo para sacar una estructura de carpetas. Del trabajo total, 50% es política entre departamentos, 20% es actualización de procesos, 20% es capacitación y solo 10% son problemas técnicos. He pasado por desastres grandes y pequeños, y por un caos interminable, así que me cuesta creer que la realidad sea tan simple solo porque una herramienta de IA haga más fácil construirla. Mi predicción escéptica es que en unos meses van a terminar restaurando backups

• La broma de “ojalá los agentes de IA respondieran a las órdenes como un peón de Warcraft 3” y que yo preferiría estar en un yate

  • Quiero señalar que "I'd rather be sailing" es una línea de Warcraft 2, y en Warcraft 3 la respuesta es "I'd rather be flying"