Sobrecarga de Responsabilidades de MCP
Una crítica común es que se le está asignando demasiada responsabilidad a MCP. El autor argumenta que MCP debería servir principalmente como una puerta de enlace para que los LLM accedan e interactúen con recursos externos. Verlo simplemente como una ‘puerta’ o un ‘puente’ ayuda a aclarar su propósito y limitaciones.
Atribuir problemas como la exposición accidental de datos, las vulnerabilidades de inyección de prompts y las deficiencias en el control de costos directamente a MCP es una atribución incorrecta de la culpa. Estos son problemas que los desarrolladores deberían abordar dentro de los límites que controlan. Los desarrolladores deben implementar límites de velocidad y monitorear el uso, independientemente del protocolo utilizado. Equiparar esto a culpar a la carretera por exceso de velocidad es apropiado: la infraestructura no es responsable del comportamiento individual.
En última instancia, muchas de las preocupaciones planteadas son problemas más amplios relacionados con la delegación de tareas a agentes de IA. Los desarrolladores deben asumir la responsabilidad de gestionar estos desafíos dentro de sus aplicaciones específicas, en lugar de esperar que la API en sí misma se encargue de todo.
La Espada de Doble Filo de los LLM y la Inyección de Prompts
Las discusiones recientes sobre MCP a menudo se asemejan a advertencias sobre los peligros inherentes de los cuchillos afilados: pueden cortar si se manejan mal. La inyección de prompts, una preocupación importante, es una consecuencia de la naturaleza de los propios LLM. Los intentos de eliminar el riesgo de inyección de prompts degradan las capacidades mismas que hacen valiosos a los LLM.
La noción de separación ‘control vs. datos’, común en los sistemas tradicionales, no existe naturalmente en los LLM. Los LLM obtienen su poder y generalidad precisamente porque carecen de esta separación rígida. Esta característica inherente los hace vulnerables a los ataques de inyección de prompts.
Si bien los MCP remotos como servicio pueden presentar riesgos, la falla no radica en el protocolo en sí, sino en confiar tareas sensibles a terceros no confiables. Esta analogía se extiende a la idea de pegar con cinta adhesiva un cuchillo a un Roomba errático: el problema no es el cuchillo en sí, sino la decisión de adjuntarlo a un dispositivo impredecible.
Las advertencias de ‘tener cuidado’ o las sugerencias de equipo de protección, aunque técnicamente precisas, pasan por alto el problema central: la decisión imprudente de combinar una herramienta afilada con un sistema incontrolado.
Desafíos de Escalabilidad
Más allá de las preocupaciones de seguridad, MCP enfrenta limitaciones fundamentales de escalabilidad. El autor destaca la correlación negativa entre la confiabilidad del LLM y la cantidad de contexto instructivo proporcionado. Esto desafía la creencia común de que agregar más datos e integraciones resolverá automáticamente los problemas. A medida que aumenta el número de herramientas e integraciones, el rendimiento de un agente puede degradarse y aumentar simultáneamente el costo de cada solicitud.
El autor enfatiza que MCP no escala más allá de cierto umbral. Intentar agregar un número ilimitado de herramientas al contexto de un agente inevitablemente impactará negativamente sus capacidades. Esta limitación es inherente al concepto de MCP y requiere más atención que los problemas de autenticación.
Los usuarios pueden eventualmente experimentar una disminución en el rendimiento a medida que habilitan más servidores MCP, lo que lleva a la interferencia entre ellos. Esto contrasta marcadamente con los sistemas típicos de gestión de paquetes, donde la no interferencia es una propiedad fundamental.
El problema central con MCP es que su comportamiento real se desvía de las expectativas del usuario. Es crucial reconocer que MCP no es una solución ‘plug-and-play’ que integra sin problemas un número ilimitado de herramientas sin consecuencias.
Abordar las Limitaciones con la Interfaz de Usuario y la Gestión de Herramientas
Una solución propuesta a las limitaciones de MCP es mejorar la interfaz de usuario. Si una herramienta se ejecuta involuntariamente, la interfaz de usuario debe proporcionar una manera fácil de deshabilitarla o modificar su descripción para aclarar su uso previsto.
El autor también señala que el crecimiento del contexto a menudo conduce a un mejor rendimiento y capacidades de uso en el mundo real, lo que contradice la noción de una correlación estrictamente negativa. Sin embargo, reconocen que en ciertos casos de uso o con contextos mal diseñados, puede ocurrir una degradación del rendimiento.
Para abordar la abrumadora elección de herramientas, se sugiere un enfoque de ‘divide y vencerás’. Esto implica agregar una herramienta diseñada específicamente para seleccionar las herramientas más relevantes para una tarea dada. Esta ‘herramienta de elección de herramientas’ podría ser otra llamada a LLM, encargada de devolver un subconjunto de herramientas disponibles al agente ‘principal’. Este enfoque en capas agrega niveles adicionales de indirección para gestionar la complejidad.
Sin embargo, simplemente tener herramientas en el contexto puede alterar significativamente la salida de un modelo. Si bien las herramientas contextualmente relevantes (logradas a través de técnicas como la Generación Aumentada por Recuperación o RAG) son beneficiosas, ocultar todas las herramientas detrás de una solicitud ‘get_tools’ puede ser perjudicial.
MCP como Capa de Transporte y Autorización
MCP funciona principalmente como un transporte y un formato de cable con un ciclo de vida de solicitud/respuesta, centrándose en la autorización a nivel de herramienta. El ensayo argumenta que el mayor problema con MCP es su incapacidad para permitir que los agentes de IA compongan funcionalmente herramientas.
El autor postula que MCP puede ser innecesario en primer lugar, ya que los LLM ya poseen la capacidad de interactuar con las API documentadas utilizando las especificaciones de OpenAPI. El elemento que falta es la autorización: la capacidad de controlar a qué API puede acceder una IA. En lugar de MCP, el autor sugiere permitir que las IA realicen solicitudes HTTP mientras aplican la autorización a puntos finales específicos. Este enfoque se alinea con la tendencia actual de envolver las API existentes con herramientas MCP delgadas.
Un aspecto particularmente molesto de MCP es su falta de soporte para la transmisión de resultados de llamadas a herramientas. El único par solicitud/respuesta obliga a los clientes a llamar repetidamente a las herramientas para la paginación, lo que dificulta los procesos de larga duración. La implementación de una capacidad de transmisión, quizás utilizando gRPC, podría mejorar significativamente la eficiencia de MCP.
La Facilidad de Exponer Datos Confidenciales
Una preocupación importante con MCP es el potencial de fácil exposición de datos confidenciales. Además, MCP no hace inherentemente que los agentes de IA sean más confiables; simplemente les otorga acceso a más herramientas, lo que paradójicamente puede disminuir la confiabilidad en ciertas situaciones.
El autor reconoce que no espera que MCP resuelva o sea responsable de todos estos problemas. Más bien, MCP crea una superficie más grande para estos problemas, lo que requiere que los desarrolladores y usuarios de la aplicación estén atentos.
Analogías y Planificación Urbana
El autor utiliza la analogía de la planificación urbana para ilustrar el problema. Comparar MCP con una carretera urbana de seis carriles con un límite de velocidad de 25 mph destaca la desconexión entre el diseño y el uso previsto. Simplemente imponer multas o agregar ‘arreglos’ superficiales no aborda el problema subyacente del mal diseño.
La planificación urbana eficaz implica el diseño de carreteras que fomenten naturalmente el cumplimiento de los límites de velocidad. De manera similar, MCP debe diseñarse para mitigar inherentemente los riesgos potenciales, en lugar de depender únicamente de controles externos.
LLM Tomando Acciones No Deseadas
El artículo cambia a una crítica más amplia de los protocolos que permiten a los LLM ejecutar acciones en los servicios. El autor identifica un problema central: los LLM pueden tomar acciones que los usuarios no pretenden que tomen. Distinguen entre las acciones que los LLM pueden tomar independientemente y las que requieren la indicación del usuario.
Si bien el objetivo final puede ser que los LLM administren empresas enteras, la tecnología aún no está lista para tal autonomía. Actualmente, es posible que los usuarios ni siquiera quieran que las IA envíen correos electrónicos sin una revisión previa.
El autor rechaza la solución de pedirle al usuario confirmación, citando el riesgo de que los usuarios caigan en un patrón de confirmación automática (‘modo YOLO’) cuando la mayoría de las herramientas parecen inofensivas. Esto se compara con el fenómeno psicológico de que las personas gastan más con tarjetas que con efectivo: un problema arraigado en el comportamiento humano, no en la tecnología.
La Pregunta Fundamental: ¿Por Qué No Simplemente Usar APIs?
Una pregunta recurrente en las discusiones sobre MCP es por qué no simplemente usar APIs directamente.
MCP permite que los clientes LLM que los usuarios no controlan directamente (por ejemplo, Claude, ChatGPT, Cursor, VSCode) interactúen con las API. Sin MCP, los desarrolladores necesitarían construir clientes personalizados utilizando las API de LLM, una tarea mucho más costosa que utilizar los clientes existentes con una suscripción y enseñarles cómo usar herramientas específicas.
Un desarrollador comparte su experiencia de construir un servidor MCP para conectarse a su sintetizador de hardware FM a través de USB, lo que permite el diseño de sonido impulsado por IA.
Integración de Clientes LLM y Estandarización
El problema central es que no todos los clientes LLM admiten nativamente la interacción directa con la API, siendo las acciones GPT personalizadas de ChatGPT una excepción notable. Anthropic, Google y OpenAI han acordado adoptar MCP como un protocolo compartido para simplificar el proceso para clientes impulsados por LLM como Claude, ChatGPT y Cursor.
MCP simplifica el proceso para aquellos que construyen clientes LLM. Si desea que un LLM interactúe con una API, no puede simplemente proporcionar una clave de API y esperar que funcione; debe crear un Agente.
MCP puede verse como una forma de documentar las API y describir cómo llamarlas, junto con herramientas estandarizadas para exponer esa documentación y facilitar las llamadas. Proporciona la abstracción justa para envolver las API sin complicaciones innecesarias, pero esta simplicidad también puede llevar a los usuarios a ‘dispararse en el pie’.
La Eficiencia y Reusabilidad de MCP
Sin MCP, los desarrolladores necesitarían explicar repetidamente al LLM cómo usar una herramienta cada vez que se invoca. Esto conlleva el riesgo de que el LLM no use la herramienta correctamente debido a información olvidada o al comportamiento no estándar de la API.
Esta constante explicación y duplicación desperdicia tokens en el contexto, lo que aumenta los costos y el tiempo. MCP simplifica este proceso agrupando toda la información necesaria, haciendo que el uso de la herramienta sea más eficiente y facilitando el uso compartido de la herramienta.
Al decirle a un proveedor de LLM ‘aquí hay una herramienta que puede usar’ junto con la documentación de la API, los usuarios pueden reutilizar esa herramienta en múltiples chats sin recordatorios repetidos. Esto también permite que los clientes LLM de escritorio se conecten a programas que se ejecutan localmente, abordando el problema de los procesos de ejecución específicos del sistema operativo.
MCP y Acceso a Recursos Locales
MCP facilita el acceso a recursos locales como archivos, variables de entorno y acceso a la red para LLM. Está diseñado para ejecutarse localmente, otorgando al LLM acceso controlado a estos recursos.
La ‘forma’ de llamada a herramienta LLM estándar refleja fielmente la ‘forma’ de llamada a herramienta MCP, lo que la convierte en un estándar sencillo para conectar herramientas a agentes.
MCP actúa como un puente entre el esquema de llamada a función expuesto al modelo de IA y las API subyacentes. Traduce las llamadas a función en herramientas, lo que permite una comunicación fluida.
Si es un proveedor de herramientas, MCP ofrece un protocolo estandarizado para que las interfaces de IA agente se conecten a su herramienta. Esto responde a la pregunta de por qué el protocolo estándar no puede ser simplemente HTTP y OpenAPI.
MCP es una meta-API que incorpora puntos finales y sus detalles operativos en la especificación, lo que permite a los LLM interactuar con ellos de manera más efectiva.
MCP en Escenarios Específicos
MCP puede resolver problemas cuando los usuarios hacen preguntas o no están seguros de qué API usar. También puede procesar solicitudes basadas en mensajes anteriores.
Un usuario comparte su experiencia de querer recuperar la ‘X’ de un usuario y enviarla a un punto final. Descubrieron que MCP era exagerado para una tarea tan simple, lo que indica que no siempre es necesario para las interacciones básicas de la API.
MCP se compara con un marco de aplicación web FastAPI para construir software que puede comunicarse a través de la red, diseñado específicamente para experiencias agénticas. Puede verse como ‘Rails-for-Skynet’, proporcionando un marco estandarizado para el desarrollo de agentes de IA.
Preocupaciones Sobre el Control del Proveedor
Existen preocupaciones de que se esté impulsando MCP para aumentar el control del lado del proveedor sobre el sistema. Los proveedores de LLM eventualmente podrían restringir el acceso a la API, de manera similar a como Google dificultó el uso de IMAP/SMTP con Gmail.
El uso de OpenAPI permite a los agentes recuperar las especificaciones de la API desde /openapi.json.
MCP permite interacciones rápidas, permitiendo a los usuarios realizar tareas en segundos en lugar de dedicar tiempo a preparar los datos de entrada, enviarlos a la API, analizar la salida y repetir el proceso para cada mensaje.
Sandboxing y Riesgos de Seguridad
Uno de los mayores problemas es cómo la salida de la herramienta de un servidor MCP puede afectar a otras herramientas en el mismo hilo de mensajes. Esto necesita sandboxing entre herramientas para prevenir consecuencias no deseadas. Invariant labs abordó esto con descripciones de herramientas, mientras que otros han usado archivos adjuntos de recursos MCP. La falta de sandboxing exacerba los riesgos de inyección de prompts.
Esto se compara con la inyección SQL: un sistema improvisado donde las vulnerabilidades pueden explotarse en cualquier punto con una observabilidad mínima.
La interfaz de prompt también es susceptible a una forma de inyección SQL, ya que el modelo no puede distinguir las partes confiables del prompt de la entrada contaminada del usuario. Resolver esto requiere cambios fundamentales en la codificación, la decodificación y el entrenamiento del modelo.
Esto permite tanto la inyección de prompts como la inyección de herramientas, lo que puede conducir a la ejecución de código no confiable.
Contenedorización y Acceso Controlado
Un desarrollador creó un servidor MCP que inicia un contenedor Docker con el código del proyecto montado. Este enfoque permite que el LLM acceda a todo el conjunto de herramientas Unix y a las herramientas específicas del proyecto dentro de un entorno sandbox.
Este flujo de trabajo agéntico, impulsado a través de una interfaz basada en chat, ha demostrado ser más eficaz que los métodos tradicionales.
La clave es otorgar a los agentes MCP acceso a lo que necesitan, y nada más. La contenedorización y la UX de herramientas transparente son cruciales para mitigar los riesgos de seguridad.
Máquinas Virtuales y Acceso a Internet
Dar a los agentes una computadora con una instalación mínima de Linux (como una VM o un contenedor) puede producir mejores resultados, permitiéndoles obtener información de Internet. Sin embargo, esto plantea preocupaciones de seguridad con respecto a las instrucciones maliciosas y la exfiltración de datos.
Limitar el acceso a sitios web de confianza puede mitigar algunos riesgos, pero incluso las fuentes de confianza pueden alojar contenido malicioso. La compensación entre la probabilidad de encontrar instrucciones maliciosas y los beneficios de productividad debe considerarse cuidadosamente.
Las diferencias entre los empleados y los agentes de IA son significativas. Los empleados son personas jurídicas sujetas a leyes y contratos, lo que proporciona responsabilidad. Los agentes de IA carecen de este marco legal, lo que dificulta la confianza.
Las Primeras Etapas del Desarrollo de MCP
MCP solo se anunció en noviembre de 2024, y el RFC está evolucionando activamente.
Algunos ven todo el concepto de asistente personal de IA, incluido MCP, como fundamentalmente defectuoso.
El impulso inicial para los Asistentes de IA a finales de la década de 1990 y principios de la de 2000 fracasó porque los agregadores de contenido con integración vertical y poder de compra a granel demostraron ser más eficaces. Esto condujo al auge de plataformas como Expedia y eBay.
Los sistemas multiagente requieren que los programadores influyan en el estado de los agentes, una tarea de programación desafiante.
Los Límites del Valor Gratuito
El deseo de ‘clasificar los resultados por disponibilidad de estacionamiento’ destaca el problema de acceder a los datos detrás de las API de pago o las interfaces ad-supported. Es poco probable que las empresas proporcionen libremente acceso a todo su conjunto de datos a través de una API.
Si bien no todas las empresas integrarán sus datos en los agentes de IA, el potencial de combinar varias herramientas para potenciar los flujos de trabajo sigue siendo significativo.
Las empresas que priorizan el mantenimiento de una fosa de datos probablemente se resistirán a las nuevas tecnologías que amenacen esa fosa.
Si booking.com tuviera una API, probablemente devolvería los mismos resultados que su sitio web, posiblemente con formato JSON o XML.
Evitar al Intermediario
No tiene mucho sentido que un intermediario como booking.com permita a los usuarios evitar por completo sus servicios.
Sin embargo, los hoteles individuales podrían encontrar beneficioso evitar booking.com, un intermediario que a menudo no les gusta.
Una IA de Investigación Profunda podría buscar hoteles basados en criterios específicos e interactuar con los servidores MCP de Hotel Discovery ejecutados por hoteles individuales, evitando la necesidad de navegar por la interfaz y los anuncios de booking.com.
Casos Prácticos
MCP puede facilitar tareas como obtener registros de Elasticsearch o consultar bases de datos de una manera más estructurada.
La naturaleza estática de la configuración del servidor MCP, donde los nuevos servidores requieren editar un archivo .json y reiniciar la aplicación, puede ser limitante.
Modelos Ajustados
MCP puede verse como un modelo pequeño y afinado que entiende numerosas herramientas MCP y elige las correctas para cada conversación.
El ajuste dinámico de las herramientas basado en el contexto podría ser necesario para ciertos escenarios.
Conversaciones Abiertas y Problemas Comerciales
MCP es muy adecuado para sistemas de conversación generales y abiertos sin un flujo predefinido. Sin embargo, no es una solución única para todos los problemas comerciales. No está destinado a reemplazar marcos como LangChain.
La alternativa a MCP, un estándar abierto impulsado por la comunidad, son protocolos fracturados, propietarios y vendor-locked. Un estándar defectuoso pero en evolución es preferible a ningún estándar.
La mejor manera de ver MCP es como un cambio de desarrolladores individuales que construyen wrappers de cliente alrededor de las API a proveedores de API o wrappers mantenidos por la comunidad que los construyen. Esto proporciona una gran caja de herramientas, similar a NPM o PyPi. Sin embargo, la orquestación, la seguridad y la definición de uso aún son necesarias.
La próxima generación de Langchains se beneficiará de esta caja de herramientas más grande, pero aún se necesita innovación.
Herramientas Específicas del Usuario
En algunos casos, las herramientas podrían ser específicas de los datos del usuario, como las herramientas para cortar y manipular archivos CSV cargados.
Un problema que a menudo se pasa por alto es que MCP puede saturar el contexto del modelo con demasiadas opciones. La priorización y la exposición de metadatos son cruciales para evitar el uso derrochador de tokens y el comportamiento errático del modelo.
Estándares y Tecnología en Evolución
Nuevos estándares surgen con el tiempo, y ha pasado tanto tiempo desde que los estándares realmente importaron que la gente ha olvidado cómo se desarrollan.
Descargar pequeños programas de servidor de desarrolladores aleatorios para agregar ‘herramientas’ a los clientes LLM puede ser arriesgado.
Los problemas planteados son problemas legítimos que el ecosistema MCP necesita abordar. Algunas soluciones estarán dentro de la especificación MCP, mientras que otras serán externas.
Código de Claude y Uso en el Mundo Real
Existen opiniones contrastantes sobre el éxito de MCP. Algunos han escuchado historias de empresas que se integran con MCP, mientras que otros han escuchado de usuarios que lo encontraron decepcionante.
Esto destaca el inconveniente de la exageración y la adopción temprana.
Algunos desarrolladores encuentran que las API HTTP son superiores a MCP para la mayoría de los casos de uso. Argumentan que el uso de ‘herramientas’ se reduce a los puntos finales de la API para las capacidades y la funcionalidad.
Las API no son autodescriptivas de forma predeterminada, lo que representa una oportunidad perdida para que los proponentes de REST y HATEOAS muestren sus enfoques.
¿MCP como Alternativa a LangChain?
MCP ha sido descrito como teniendo un ‘olor a LangChain’: no resuelve un problema acuciante, es demasiado abstracto y tiene dificultades para explicar sus ventajas.
¡Quizás necesita decir ‘FIN DE LÍNEA’ y desterrar a los aspirantes a hackers a la red de juegos!
Una pregunta clave es si el paradigma de Chatbot ‘general’ persistirá. Las aplicaciones especializadas con sus propias herramientas podrían no necesitar MCP.
Por el contrario, a medida que los LLM se vuelven más capaces, las herramientas externas podrían volverse menos necesarias. ¿Por qué querrías un MCP para controlar Photoshop cuando el LLM podría simplemente editar la imagen directamente?
El sueño del asistente robótico de ciencia ficción puede no materializarse, y las herramientas especializadas de manipulación del lenguaje podrían ser más útiles.
La Base de Usuarios y la Conciencia de Seguridad
La base de usuarios de MCP incluye personas menos técnicas, lo que hace que los problemas de seguridad sean particularmente relevantes. Aumentar la conciencia de las mejores prácticas de seguridad es crucial.
Basar Xops en OpenRPC, que requiere definir el esquema de resultados, ayuda a planificar cómo las salidas se conectan a las entradas, mejorando la confiabilidad para flujos de trabajo complejos.
Es probable que la tecnología evolucione y se establezca con el tiempo.
Redundancia e Infraestructura en la Nube
Algunos cuestionan las ganancias de usar MCP sobre el estándar OpenAPI, viéndolo como redundante.
¿Qué usará el LLM para llamar a un sistema OpenAPI? ¿Cómo se vinculará a la shell? ¿Cómo orquestará eso el host del LLM?
MCP proporciona una forma estructurada para que los LLM hagan llamadas a herramientas.
Los servidores MCP ya son servidores HTTP.
La mayor ventaja de MCP es para los proveedores de LLM como OpenAI, no para los desarrolladores de aplicaciones.
Los LLM son cerebros sin herramientas, y la llamada a herramientas los empodera. Sin embargo, con las API normales, los proveedores de LLM carecen de acceso a esas herramientas. MCP les otorga acceso, posicionándolos como la puerta de entrada a la IA.
CLI vs. API
¿Por qué no usar la CLI directamente, dado que los LLM están entrenados en lenguaje natural y las CLI son una solución común legible y grabable por humanos?
MCP surgió demasiado rápido y necesita tiempo para madurar. Carece de la aprobación de un organismo de estándares convencional y está impulsado por la exageración.
Hay una falta de aplicaciones en el mundo real.
Aplicaciones Clave de MCP
MCP se utiliza en Claude Desktop y aplicaciones de chat de IA de nicho, herramientas de automatización de código y marcos de automatización de agentes/LLM.
Es otra tecnología apresurada que probablemente se descartará cuando llegue el próximo acrónimo hype-able.
Hay dos tipos de protocolos de llamada a herramientas de modelos de lenguaje: los que la gente critica y los que nadie usa.
Anthropic desarrolló este ‘estándar’ en un vacío, lo que lleva a problemas de seguridad.
JSON-RPC 2.0
MCP está construido sobre JSON-RPC 2.0, un protocolo ligero que permite la comunicación cliente-servidor usando JSON.
Se siente como una especificación centralizada diseñada para un ecosistema específico, reclamando la universalidad sin ganársela.
MCP es lo suficientemente potente como para hacer cosas útiles, lo que plantea preocupaciones de seguridad.
No es un estándar maduro y no fue diseñado para ser seguro.
Si bien existen recomendaciones, no se aplican ni se implementan.
Langchain y Llamada a Herramientas
Langchain es uno de los muchos marcos que implementan el patrón de ‘llamada a herramientas’.
MCP es una especificación de cómo la información externa ingresa a la ventana de contexto de un modelo de lenguaje, incluyendo la llamada a herramientas, la entrada basada en plantillas, la cancelación, el seguimiento del progreso y el estado de los servidores de herramientas.
Ayuda a estandarizar los detalles para que cualquier combinación de asistente/integración sea compatible.
Si bien MCP tiene problemas legítimos, los críticos deberían refinar sus argumentos.
La autenticación es crucial y no debería haberse omitido de la versión inicial.
Hay demasiadas complejidades.