Los agentes funcionan distinto con MCP y CLI, y el método DART aportó hasta +9 puntos

Cuando un agente de IA usa herramientas, no ve las capacidades «en limpio», sino su descripción: o bien como un conjunto de funciones mediante el protocolo MCP (Model Context Protocol, el estándar para conectar herramientas a un modelo de lenguaje), o bien como comandos en una terminal, es decir, CLI. Un equipo de ModalityDance (Zhenning Shi, Liang Pang, Yongqi Li) se planteó una pregunta directa: si las capacidades son exactamente las mismas y solo cambia la forma de mostrárselas al modelo, ¿cambia el comportamiento del agente? La respuesta es que sí, y mucho.

Divergieron la calidad en la resolución de tareas, el consumo de tokens (las unidades de texto por las que se paga al usar un modelo) e incluso la manera en que el agente comete errores y se recupera de ellos. Además, los autores propusieron el método DART, que mejoró los resultados en las seis configuraciones probadas, con una subida de hasta 9,0 puntos.

Cómo lograr una comparación justa

Por lo general, MCP y CLI se comparan «tal cual». Pero así no se sabe qué influyó realmente en el resultado: la propia interfaz, o el hecho de que una tenga herramientas más ricas y la otra las implemente de otro modo. Para eliminar esa confusión, los autores construyeron el banco de pruebas MICA (Matched Interface Comparison and Analysis, «comparación y análisis de interfaces equivalentes»).

Funciona así:

• existe un contrato único de acciones semánticas: la lista de lo que el agente puede hacer; • a partir de ese contrato se generan automáticamente dos versiones: MCP y CLI; • elija lo que elija el agente, la acción se decodifica y llega al mismo código de ejecución.

Es decir, bajo el capó las capacidades coinciden por completo. La diferencia queda solo en el «escaparate»: cómo se describen las acciones, cómo hay que escribirlas y qué aspecto tiene la respuesta del entorno. Las pruebas se ejecutaron con seis modelos y en tres entornos interactivos.

Dónde se separan los caminos del agente

Primer resultado: el rendimiento y el coste de la interacción difieren de forma notable. Y no se trata solo de erratas de sintaxis, cuando el agente escribe mal una llamada. La interfaz influye en qué acción elige el agente según su significado, en cómo falla y en cómo se recupera tras un fallo.

Para localizar el origen de esa sensibilidad, los investigadores recurrieron a dos técnicas.

• Sondeos con el mismo estado. Colocaban al agente en la misma situación y modificaban por separado tres elementos: cómo se presentan las capacidades, cómo se escribe la acción y cómo se devuelve la retroalimentación. Así pudieron ver cuál de las tres partes desorienta más al modelo. • Trayectorias naturales emparejadas. El agente resolvía la misma tarea mediante MCP y mediante CLI. De 2004 episodios, en el 94,3% se encontró una divergencia estructural, es decir, en aproximadamente 1890. Las diferencias tempranas no se diluían, sino que se arrastraban: un solo paso fallido al principio alteraba todo el curso posterior de la interacción.

La conclusión de los autores: la interfaz forma parte del circuito cerrado de toma de decisiones. El agente actúa, recibe una respuesta y decide de nuevo, y la forma de la respuesta y de la escritura influye en cada paso siguiente. No es una envoltura neutra alrededor del modelo.

DART: reparar la escritura del comando, no la decisión

Puesto que la divergencia aparece en la fase de «realización» de la acción, es ahí donde se puede corregir. El método DART (Decoupled Action Realization and Targeted Repair, «realización desacoplada de la acción y reparación puntual») divide el trabajo en dos partes. Primero, el agente determina qué quiere hacer exactamente. Esa decisión semántica se verifica y se guarda. Después, un paso aparte se encarga de cómo escribir esa decisión en el lenguaje de la interfaz concreta y, si hay errores, repara solo esa escritura. El sentido de la acción elegida no se revisa.

Efecto según las cifras declaradas:

• la puntuación en los benchmarks subió en las seis configuraciones probadas (modelo más entorno), con un máximo de 9,0 puntos; • el coste de MCP bajó en los tres entornos, con un máximo de 27,1 mil tokens por tarea.

La segunda cifra importa para el presupuesto. Las descripciones de herramientas y las respuestas de MCP suelen ser extensas, y hay que pasarlas por el contexto en cada paso. Si no se repite parte del trabajo, el consumo baja de forma notable.

Qué implica esto para los ingenieros

El debate «MCP contra CLI» planteado así pierde sentido: no se puede determinar un ganador sin controlar cómo está implementada la interfaz. Un mismo modelo con las mismas herramientas puede parecer más fuerte o más débil según la forma en que se presenten.

Conclusiones prácticas:

• al comparar modelos y frameworks de agentes, fije la interfaz y descríbala en el informe; de lo contrario, las cifras no son comparables; • conviene analizar los fallos del agente por niveles: si se equivocó al elegir la acción o solo al escribir la llamada; • si construye un agente sobre MCP y paga por tokens, tiene sentido separar la decisión semántica de su formulación y corregir solo la formulación.

También se ven las limitaciones: el estudio abarca seis modelos y tres entornos, así que conviene extrapolar las cifras con cautela a cualquier otro conjunto de tareas. El código y la página del proyecto son abiertos (repositorio ModalityDance/MICA en GitHub), por lo que los resultados pueden verificarse con agentes propios.