Contratos de herramienta: Por qué los Agents omiten tus herramientas

La ejecución de evaluación que inició este documento parecía saludable a primera vista. Estaba realizando evaluaciones con un conjunto de oro contra un agente de grado de producción para una prueba de valor empresarial: un conjunto curado de tareas, cada una con una secuencia esperada de llamadas a herramientas, reproducidas contra el agente y puntuadas automáticamente. Los rastros de razonamiento eran genuinamente buenos. El modelo descomponía los problemas correctamente, planificaba de manera sensata y escribía respuestas finales claras. Y estaba omitiendo herramientas que debía llamar en más del 20 por ciento de los casos. No fallaba las llamadas. No las llamaba con argumentos incorrectos. Simplemente respondía en silencio por su cuenta como si la herramienta no existiera.

Mi primer instinto fue el habitual: cambiar el modelo y luego reescribir el prompt del sistema. Ninguna de las dos cosas movió mucho el número. Un modelo más caro redujo unos pocos puntos la tasa de omisión a 13 veces el costo. La cirugía de prompt (“DEBES usar las herramientas disponibles”) produjo el fallo opuesto: el agente comenzó a llamar herramientas que no necesitaba. Lo que finalmente lo arregló fue aburrido: reescribí las descripciones de las herramientas. Indiqué cuándo debía usarse cada herramienta, cuándo no y qué devolvía. Moví las restricciones de la prosa al esquema. La tasa de omisión se redujo a un solo dígito bajo. El mismo modelo, el mismo prompt del sistema, el mismo conjunto de evaluación.

Ese resultado se repitió en cada agente que evalué después, y cambió mi forma de pensar sobre los fallos en la llamada a herramientas. La causa dominante no es la debilidad del modelo. Son los contratos de herramientas insuficientemente especificados: descripciones vagas, herramientas superpuestas, esquemas que aceptan basura, restricciones que solo existen en la cabeza de un desarrollador. Los equipos escriben especificaciones de herramientas para desarrolladores que pueden leer el código fuente. El lector real es un modelo probabilístico que ve exactamente el JSON que registraste y nada más. Esta guía es lo que hago ahora al respecto, incluyendo el linter determinista que construí para hacerlo aplicable en CI.

Una taxonomía de los fallos en la llamada a herramientas

Cuando puntúo las transcripciones de evaluación, cada fallo relacionado con herramientas cae en uno de cinco cubos. La disciplina útil es rastrear cada cubo hasta el defecto de especificación que lo causó, porque eso te dice qué arreglar. Culpar al “modelo” no te dice nada accionable.

Modo de fallo	Cómo se ve en la transcripción	Causa raíz en la especificación	Cómo detectarlo en las evaluaciones
Omisión	No hay llamada a la herramienta donde se requería una; el agente responde a partir de conocimiento paramétrico o adivina	La descripción no dice cuándo se aplica la herramienta, o no establece que sus datos son actuales y autoritativos	El rastro de oro espera la herramienta X; la transcripción no contiene ninguna llamada a X. Informar las omisiones por herramienta, no solo en general
Herramienta incorrecta	El agente llama a un vecino plausible: search_documents en lugar de search_customer_accounts	Herramientas superpuestas con descripciones casi idénticas y sin cláusula de desambiguación	Se esperaba la herramienta A, se observó la herramienta B. Agrupar las confusiones en una matriz; los pares superpuestos se iluminan inmediatamente
Argumentos mal formados	La llamada falla la validación del esquema o la API devuelve 400; el agente reintenta ciegamente o se rinde	El esquema es demasiado laxo: parámetros sin tipo, sin array required, campos de cadena libre donde existen formatos	Contar los fallos de validación de esquema y las respuestas 4xx por herramienta en los rastros
Argumentos alucinatorios	Los argumentos son sintácticamente válidos pero inventados: un ID de cuenta que no aparece en ninguna parte de la conversación	La especificación carece de restricciones y ejemplos, por lo que el modelo llena los huecos con valores de aspecto plausible	Comparar los valores de los argumentos con los valores realmente presentes en la conversación o en los resultados de herramientas anteriores
Respuesta prematura	El agente produce una respuesta final segura sin llamar a las herramientas que la fundamentan	La descripción no le dice al modelo que su conocimiento está obsoleto aquí (“los datos de la cuenta cambian diariamente; llama a esto incluso si crees que lo sabes”)	Respuesta final presente, llamadas requeridas ausentes; verificar si las afirmaciones de la respuesta son rastreables a la salida de la herramienta

Dos cosas sobre esta tabla se ganaron su lugar a través de la repetición. Primero, la omisión es el fallo más común y el menos visible. Una llamada mal formada arroja un error sobre el que puedes alertar. Una omisión produce una respuesta fluida, segura y errónea, y nada en tus registros la señala. Solo ves omisiones si tus evaluaciones codifican qué llamadas a herramientas se esperaban. Segundo, cuatro de los cinco cubos son defectos de especificación. Solo la selección de herramienta incorrecta en un conjunto de herramientas genuinamente bien separado es plausiblemente una limitación del modelo, e incluso allí la especificación suele ser cómplice.

La descripción de tu herramienta es un prompt. Se inyecta en la ventana de contexto en cada turno. La mayoría de los equipos pasan semanas iterando el prompt del sistema y cero minutos en los quince prompts que enviaron junto con él.

Qué es realmente un contrato de herramienta

Uso la palabra contrato deliberadamente. Una herramienta se encuentra en el límite entre dos sistemas muy diferentes: una implementación determinista que hace exactamente lo que dice su código, y un llamador probabilístico que decide si invocarla y cómo, basándose puramente en el texto y el esquema que registraste. El modelo no puede leer tu código fuente. No puede preguntar a un colega. La especificación es la interfaz completa, y tiene seis partes:

1. Nombre. La señal individual más fuerte para la selección de herramientas. Los modelos hacen coincidir patrones en los nombres antes de leer una palabra de la descripción.
2. Descripción. Cuándo usar la herramienta, cuándo no y qué devuelve. Esta es una documentación donde el lector es un modelo, lo que cambia las reglas de escritura.
3. Esquema. La forma de la entrada que puede ser verificada por máquina: tipos, campos requeridos, enumeraciones, formatos, rangos.
4. Restricciones. Todo lo que el esquema no puede expresar estructuralmente, declarado explícitamente: dependencias de orden (“llama a search_customer_accounts primero para obtener el account_id”), expectativas de tasa, frescura de los datos.
5. Ejemplos. Al menos una invocación concreta y válida. Los modelos generalizan a partir de ejemplos de manera mucho más fiable que de descripciones abstractas.
6. Semántica de errores. Cómo se ve un fallo y qué debe hacer el llamador al respecto. Un agente que sabe que STATEMENT_NOT_READY significa “detenerse e informar al usuario” se comporta de manera diferente a uno que mira un rastreo de pila.

El hábito de mayor apalancamiento es escribir descripciones orientadas al comportamiento en lugar de descripciones de implementación. Una descripción de implementación dice lo que hace el código: “Consulta la base de datos de clientes a través del servicio de cuentas”. Una descripción de comportamiento dice lo que debe hacer el llamador: “Busca cuentas de clientes por nombre, correo electrónico o número de cuenta. Usa esto cuando el usuario pregunte por un cliente específico y aún no tengas su ID de cuenta”. La primera es precisa e inútil para el modelo. La segunda se lee como una regla de enrutamiento, porque así es exactamente como el modelo la consume. Cada descripción que envío ahora contiene la frase literal “Usa esto cuando” y, para cualquier herramienta con un vecino plausible, “No uses esto para”.

Las reglas que importan de forma medible

Estas son las reglas que aplico al revisar las especificaciones de herramientas, ordenadas aproximadamente por cuánto cada una movió las tasas de omisión y error en mis evaluaciones. Nada de esto es exótico. Todo ello está regularmente ausente en los servidores MCP de producción.

Una tarea por herramienta, y sin vecinos superpuestos

Si dos herramientas pudieran plausiblemente manejar la misma solicitud, el modelo dividirá sus llamadas entre ellas, y tus evaluaciones mostrarán un patrón de confusión difuminado en lugar de un fallo limpio. Los peores infractores que veo son pares como get_customer / fetch_customer_details / lookup_client que crecieron orgánicamente de diferentes equipos. Fusiónalos, o dales a cada uno un límite claramente distinto y haz referencia cruzada al otro por nombre en la descripción (“Para el historial de transacciones, usa list_account_transactions en su lugar”). Un modelo que decide entre herramientas está realizando una tarea de clasificación; tu trabajo es hacer que las clases sean separables.

Di cuándo NO usarla

Las descripciones positivas definen una región difusa. Las cláusulas negativas definen sus límites. La descripción que redujo las tasas de omisión en mi ejemplo inicial no solo decía lo que hacía la herramienta; decía “Usa esto incluso si crees que ya sabes la respuesta; los datos de tenencias cambian diariamente”. Esa única frase ataca directamente los fallos de omisión y de respuesta prematura, porque la suposición predeterminada del modelo es que su conocimiento paramétrico es adecuado. Por el contrario, las cláusulas “No uses esto para X” atacan la selección de herramienta incorrecta. Ambas direcciones importan.

Pon las restricciones en el esquema, no en la prosa

Las restricciones en prosa son sugerencias. Las restricciones de esquema son verificables, y los modelos las respetan de manera más fiable porque son estructurales. Cada vez que escribes “debe ser una fecha válida” en una descripción, podrías haber escrito un pattern o format en el esquema. Aquí hay un antes y un después de una revisión real, generalizado:

{
  "name": "get_statement",
  "description": "Gets a statement. Date should be in the right format and not in the future.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "date": { "type": "string" },
      "acct": { "type": "string" }
    }
  }
}

Todo lo que está mal aquí es invisible hasta una ejecución de evaluación: no hay un array requerido (por lo que el modelo puede omitir ambos campos), no hay formato para date (observé “el mes pasado”, “2026/05/01” y milisegundos de época en los rastros), y acct no le da al modelo nada en qué basarse, que es de donde provienen los IDs de cuenta alucinatorios. La reescritura:

{
  "name": "get_monthly_statement",
  "description": "Retrieves one closed monthly account statement as a PDF link. Use this after you have an account_id from search_customer_accounts. Do not use this for real-time balances; use get_account_balance. Returns error code STATEMENT_NOT_READY if the requested month is not yet closed; do not retry, tell the user when it will be available.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "account_id": {
        "type": "string",
        "pattern": "^ACC-[0-9]{8}$",
        "description": "Account identifier, e.g. ACC-00417233. Obtain via search_customer_accounts; never guess this value."
      },
      "month": {
        "type": "string",
        "pattern": "^[0-9]{4}-(0[1-9]|1[0-2])$",
        "description": "Statement month as YYYY-MM, e.g. 2026-05. Must be a fully closed month, not the current month."
      }
    },
    "required": ["account_id", "month"],
    "additionalProperties": false
  },
  "annotations": { "readOnlyHint": true }
}

Las enumeraciones merecen una mención especial. Cualquier parámetro con un conjunto finito de valores legales debe ser una enumeración, punto. Una cadena libre con “uno de: activo, inactivo, cerrado” en la descripción eventualmente recibirá “inactivo”, y tu backend hará lo que sea que haga con eso.

Sé honesto sobre lo requerido vs. lo opcional

Dos direcciones de fallo. Marcar un campo genuinamente requerido como opcional invita a llamadas que lo omiten, y el modelo luego aprende del mensaje de error, desperdiciando un turno. Marcar un campo opcional como requerido obliga al modelo a inventar un valor, lo cual es una alucinación que creaste por decreto. Veo esto último constantemente en especificaciones generadas a partir de DTOs de backend donde cada campo era requerido para la base de datos, no para el llamador. La regla: required refleja lo que la herramienta necesita para hacer un trabajo útil, y la descripción de cada campo opcional dice qué sucede cuando se omite (“Omitir para buscar todos los estados”).

Fallar con códigos, no con prosa

Los mensajes de error son parte del contrato porque el agente los lee y decide qué hacer a continuación. Un rastreo de pila en bruto o un “error interno” genérico le da al modelo dos opciones: reintentar ciegamente o disculparse. Un código de error determinista con una pista accionable por máquina le da una rama a seguir. El patrón que uso: un campo code estable, un mensaje legible por humanos de una sola frase, y cuando sea aplicable una directiva (retry_after_seconds, “obtén primero un account_id válido”). En las evaluaciones, esto convierte una clase de transcripciones sin salida en recuperaciones, y hace que las aserciones de fallo en tu suite de pruebas sean triviales de escribir.

Nombra para el llamador, no para la base de código

Verbo-objeto, snake_case, sin jerga interna. search_customer_accounts es mejor que queryCustDB, cst_lkp_v2 y CustomerAccountSearchServiceEndpoint. Los nombres de sistemas internos son especialmente costosos: el modelo no tiene idea de que “Falcon” es tu motor de precios, por lo que query_falcon bien podría no tener etiqueta. El nombre debe permitir que un modelo sin contexto organizacional prediga lo que hace la herramienta. Esto suena cosmético. No lo es; los nombres son el filtro de primera pasada en la selección de herramientas, y en las matrices de confusión puedo ver cómo herramientas mal nombradas pierden llamadas a vecinos mejor nombrados que hacen lo incorrecto.

Respeta el presupuesto de longitud

La longitud de la descripción tiene un punto óptimo. Por debajo de unas diez palabras, la herramienta está insuficientemente especificada y se omite o se usa incorrectamente. Más allá de un par de cientos de palabras, la señal se ahoga: la cláusula de cuándo usarla está enterrada en el cuarto párrafo y el modelo tiene otras quince descripciones de herramientas compitiendo por atención en la misma ventana de contexto. En mis revisiones, las descripciones que mejor funcionan tienen de tres a seis frases: qué hace, cuándo usarla, cuándo no, qué devuelve, comportamiento de error. Si necesitas más que eso, la herramienta probablemente está haciendo demasiadas tareas (ver regla uno) o el material extra pertenece al esquema.

Puntuación determinista de especificaciones

Después de suficientes de estas revisiones, noté que aplicaba la misma lista de verificación cada vez, y una lista de verificación que aplicas a mano es un linter que aún no has escrito. Así que construí uno: Tool Credit Score, parte de Agent Contract Studio, de código abierto y funcionando en vivo en agentic-contract-studio.vercel.app. Pegas una especificación de herramienta MCP (o la importas de GitHub, o la descubres de un servidor MCP en ejecución), y puntúa cada herramienta de 0 a 100 contra una rúbrica determinista, luego auto-corrige lo que puede.

La rúbrica tiene cinco categorías ponderadas, que se corresponden directamente con la taxonomía de fallos anterior:

Categoría	Peso	Qué verifica	Modo de fallo al que apunta
Descripción	25%	Presente, más de 10 palabras, comienza con un verbo de acción, menos de 200 palabras	Omisión, respuesta prematura
Parámetros	25%	El esquema es type: object; cada parámetro tiene un tipo y una descripción; existe un array required y es honesto	Argumentos mal formados y alucinatorios
Mejores prácticas	20%	Anotaciones MCP (readOnlyHint, destructiveHint, idempotentHint); additionalProperties: false; la descripción menciona retornos y errores	Herramienta incorrecta, manejo de errores sin salida
Nomenclatura	15%	snake_case, prefijo de verbo, menos de 64 caracteres	Herramienta incorrecta
Ejemplos	15%	Al menos una invocación de ejemplo válida	Argumentos mal formados y alucinatorios

Las puntuaciones se resumen en una calificación con letra (90+ es una A, menos de 60 es una F), y el auto-corrector maneja las reparaciones mecánicas de forma determinista: renombrar a snake_case con un prefijo de verbo, añadir tipos de parámetros faltantes, andamiar ejemplos y anotaciones. Hay un pase opcional de pulido de LLM para la redacción de la descripción, pero es exactamente eso, opcional, solo local, y nunca toca los nombres de los parámetros, los tipos o la estructura del esquema. El pipeline central no necesita modelo ni clave de API.

Esa última decisión de diseño es el punto clave, y vale la pena defenderla porque “simplemente hacer que un LLM revise la especificación” es la alternativa obvia. Elegí el linting determinista para CI por cuatro razones. Es reproducible: la misma especificación obtiene la misma puntuación en cada ejecución, por lo que una regresión de puntuación en una solicitud de extracción significa que la especificación cambió, no el estado de ánimo del juez. Es rápido y gratuito, por lo que puedes ejecutarlo en cada commit sin una conversación sobre el presupuesto de tokens. Es explicable: cada punto deducido se asigna a una regla nombrada con una solución concreta, que es lo que quieres en un comentario de revisión de código. Y no se puede discutir, lo cual importa más de lo que debería; he visto a equipos volver a litigar el veredicto de un juez LLM durante una hora, y nadie discute con una expresión regular.

La advertencia honesta: un linter verifica la forma, no el significado. Tool Credit Score detectará un array required faltante cada vez; no puede decirte que dos de tus herramientas se superponen semánticamente, o que tu cláusula de cuándo usarla es fácticamente incorrecta sobre tu propio sistema. Esos defectos solo salen a la luz en las evaluaciones (tasas de omisión y confusión medidas) o en una revisión humana. El trabajo del linter es asegurarse de que los defectos mecánicos y baratos nunca lleguen a esa etapa, para que el costoso esfuerzo de revisión se dirija a donde realmente se necesita.

Una puntuación de Tool Credit Score superior a 90 no garantiza que los agentes usarán bien tus herramientas. Una puntuación inferior a 60 casi garantiza que no lo harán. El linting es un piso, no un techo.

Dónde los servidores MCP concentran estos fallos

MCP hizo que las herramientas fueran portátiles, lo cual es genuinamente útil, y también hizo que las especificaciones deficientes fueran portátiles. Tres patrones explican la mayoría de los servidores con baja puntuación que he revisado.

Servidores generados a partir de OpenAPI. Apunta un conversor a un documento OpenAPI y obtendrás un servidor MCP en minutos: una herramienta por endpoint, nombres de parámetros tomados directamente del backend, descripciones que fueron escritas para desarrolladores que leen la documentación de referencia de la API, si es que fueron escritas. El resultado es una superficie de especificación con la forma de tu base de datos, no de las tareas de tus usuarios. Un agente que se enfrente a post_v2_accounts_search, get_accounts_by_id y get_accounts_search_legacy producirá exactamente la matriz de confusión que predecirías. Los servidores generados son un buen punto de partida; no son un contrato listo para enviar. Presupuesta un pase de curación que fusione las herramientas con forma de endpoint en herramientas con forma de tarea.

Servidores “todo en uno”. Un servidor que envuelve un producto SaaS completo y expone 80 herramientas porque la API tiene 80 capacidades. Cada una de esas definiciones de herramientas se inyecta en el contexto del modelo en cada turno, por lo que pagas por toda la superficie en tokens, ya sea que esta conversación lo necesite o no, y la precisión de la selección de herramientas se degrada a medida que el conjunto de candidatos crece, especialmente cuando los candidatos comparten un vocabulario. Mi presupuesto de trabajo: mantener las herramientas realmente expuestas a un agente para una tarea dada por debajo de unas 20. Ese número es una observación de mis evaluaciones, no una ley, y los modelos mejores siguen empujándolo hacia arriba. La dirección del efecto se ha mantenido para cada modelo que he probado.

Sin divulgación progresiva. La solución para el “todo en uno” no es eliminar la capacidad, es organizar su exposición. Expón un pequeño conjunto central para la ruta común. Para capacidades de cola larga, usa un patrón de descubrimiento: una herramienta estilo search_tools que devuelve contratos completos bajo demanda, carga de esquema diferida donde tu cliente lo soporte, o subagentes dedicados que cada uno vea solo su parte del conjunto de herramientas. El diseño de MCP lo soporta: los clientes eligen qué herramientas mostrar, y el filtrado de herramientas del lado del servidor por contexto de tarea es sencillo de implementar. La disciplina del contrato sigue aplicándose en cada capa; una herramienta descubierta con una descripción vaga falla idénticamente a una precargada, solo un turno después.

El bloque annotations de MCP (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) merece más uso del que recibe. Más allá del valor de seguridad, las anotaciones permiten a un cliente aplicar una política general (aprobar automáticamente herramientas de solo lectura, proteger las destructivas con confirmación) sin analizar descripciones, y son una de las mejoras de puntuación más baratas en el linter.

Cierra el ciclo con evaluaciones

Ninguna de las reglas anteriores vale mucho como opinión. Valen mucho como deltas medidos, y la disciplina de medición es la misma que describí en Evaluación de sistemas agénticos: un conjunto de oro de tareas con secuencias esperadas de llamadas a herramientas, reproducidas contra el agente, puntuadas automáticamente. El ciclo específico para los contratos de herramientas:

1. Línea base. Ejecuta el conjunto de oro contra las especificaciones actuales. Registra la tasa de omisión por herramienta, las confusiones de herramienta incorrecta y los fallos de validación de argumentos. La granularidad por herramienta importa: una tasa de omisión agregada del 8 por ciento puede ocultar una herramienta que se omite la mitad del tiempo.
2. Arregla las especificaciones. Primero el linting (defectos mecánicos), luego aplica las reglas semánticas: límites, cláusulas de cuándo no usar, restricciones de esquema.
3. Vuelve a ejecutar el mismo conjunto de oro. El modelo, el prompt y las tareas no han cambiado, por lo que el delta es atribuible a la especificación. Este es el A/B más limpio que jamás obtendrás en la ingeniería de agentes, y es así como sé que las reescrituras de descripciones redujeron una tasa de omisión de más del 20 por ciento a un solo dígito bajo en el proyecto que inició esta guía.
4. Protégelo en CI. Las especificaciones de herramientas son código. Versiona, compara y trata un cambio de descripción como un cambio de comportamiento, porque lo es; edita un prompt que se ejecuta en cada turno. Mi pipeline falla una solicitud de extracción si la puntuación de Tool Credit Score de alguna herramienta cae por debajo del umbral, y marca cualquier diferencia de especificación para una nueva ejecución de evaluación antes de la fusión.

El mismo proyecto de gestión de patrimonio produjo el otro número que sigo citando: una vez que se arreglaron los contratos de herramientas, un modelo de nivel medio igualó la precisión del modelo premium en nuestro conjunto de oro a aproximadamente 1/13 del costo, con tasas de omisión de herramientas medidas en lugar de asumidas. Las especificaciones deficientes no solo causan fallos. Inflan silenciosamente tu factura de modelo, porque la capacidad extra del modelo caro se estaba gastando en compensar contratos que el modelo barato podría haber ejecutado si se hubieran escrito correctamente.

Lo que aún haría diferente: mis conjuntos de oro son conversaciones reproducidas, no usuarios en vivo, y los usuarios reales formulan las solicitudes de maneras que estresan la selección de herramientas más que las tareas curadas. Las tasas de omisión en producción se sitúan por encima de las tasas de omisión de evaluación para cada agente que he enviado. Trata el número de evaluación como un límite inferior y sigue muestreando los rastros de producción contra la misma taxonomía.

La versión de un párrafo

La mayoría de los fallos en la llamada a herramientas en agentes de producción son defectos de especificación, no defectos del modelo: omisiones, selecciones de herramientas incorrectas, argumentos mal formados, argumentos alucinatorios y respuestas prematuras, todos se remontan a contratos escritos para desarrolladores en lugar de para el modelo que realmente los lee. Arregla el contrato: una tarea por herramienta sin vecinos superpuestos, descripciones orientadas al comportamiento con cláusulas explícitas de cuándo usar y cuándo no usar, restricciones expresadas como enumeraciones, formatos y rangos en el esquema en lugar de prosa, un array required honesto, al menos un ejemplo, códigos de error deterministas en los que un agente pueda bifurcarse, y nombres verbo-objeto libres de jerga interna. Realiza el linting de todo esto de forma determinista en CI (mi Tool Credit Score de código abierto lo hace, de 0 a 100 con auto-corrección) porque las puntuaciones reproducibles superan las revisiones juzgadas por LLM para el control de calidad, luego prueba las correcciones semánticas con evaluaciones midiendo las tasas de omisión por herramienta antes y después. En mi trabajo de evaluación empresarial, ese ciclo redujo una tasa de omisión de herramientas de más del 20 por ciento a un solo dígito bajo sin tocar el modelo ni el prompt del sistema, y es la razón por la que un modelo de nivel medio igualó a uno premium a aproximadamente 1/13 del costo.

Referencias

• Especificación del Protocolo de Contexto del Modelo, incluyendo definiciones y anotaciones de herramientas
• Anthropic: documentación de uso de herramientas, la referencia práctica sobre cómo los modelos consumen las especificaciones de herramientas
• Ingeniería de Anthropic: escritura de herramientas efectivas para agentes
• Agent Contract Studio (Tool Credit Score), el linter determinista de especificaciones MCP descrito anteriormente, en vivo en agentic-contract-studio.vercel.app
• Evaluación de sistemas agénticos, mi guía de campo para el arnés de evaluación de donde provienen las mediciones de este documento