LLM como juez y MCP: cómo se ayudan y sus límites
Un LLM como juez es un modelo que puntúa o clasifica lo que hace otro con criterios fijados de antemano. Con MCP sirve para decidir si una llamada a una tool necesita confirmación o si su resultado es de fiar, y el propio juez puede ser un servidor MCP al que llama cualquier cliente. Lo que devuelve un juez es una señal para subir la cautela, no una prueba, y no sustituye a la confirmación de una persona. Este artículo es un extracto de nuestra guía en español, escrita contra la especificación MCP 2026-07-28. Los ejemplos son de Nortia Logística, la empresa ficticia del curso. ¿Puede un juez decidir si una tool de escritura necesita confirmación? Puede ayudar, pero solo en la zona gris y solo para subir la cautela. Lo básico de «leer sin preguntar, escribir con aprobación» ya lo resuelven reglas fijas por tool, y así lo hacen hoy ChatGPT y Claude. La especificación 2026-07-28 recomienda pedir confirmación al usuario en operaciones sensibles. Las anotaciones de una tool, como readOnlyHint o destructiveHint, son pistas que el cliente no debe creer salvo que el servidor sea de confianza. Según su documentación: En el modo desarrollador de ChatGPT, las acciones de escritura piden confirmación por defecto. ChatGPT respeta readOnlyHint y trata como escritura toda tool que no lo declare. En Claude, cada conector agrupa sus tools en lectura y en escritura o borrado, con tres estados: Always allow, Needs approval y Blocked. Ninguno de los dos documenta un juez. Lo que las reglas no cubren es que la misma tool puede ser inocua o grave según sus argumentos. El caso de Nortia: emitir_abono En nortia-facturacion, emitir_abono declara destructiveHint: true, así que el host pide aprobación a la agente de soporte antes de cada abono. El servidor comprueba con código el rol, el límite de importe y el saldo. Un abono de 184,50 EUR sobre la factura F-2026-0142 puede pasar todas las reglas con un ticket TCK-88213 ambiguo,. Ahí entra un juez rápido con una pregunta de sí o no: «¿el ticket pide de forma inequívoca este abono?». Las capas, en orden, y cada una solo actúa si la anterior deja pasar la llamada (diseño propio): Si la tool declara readOnlyHint: true, como buscar_factura, se ejecuta sin preguntar. Si no, como emitir_abono, el host pide aprobación. El servidor aplica sus reglas de rol, importe y saldo. Si no se cumplen, devuelve un error que el modelo puede leer. Si se cumplen, el juez rápido evalúa la zona gris: con confianza alta se emite el abono; con confianza media, error del juez o sin respuesta, se pide confirmación explícita con elicitation; con confianza baja no se ejecuta y el caso pasa a la controller financiera. La regla que más nos importa funciona como un trinquete, que solo gira en un sentido. El juez puede subir la exigencia, de confirmar a escalar a una persona, pero nunca bajarla. Si falla o tarda, el servidor pide confirmación. ¿Se puede detectar una inyección en lo que devuelve una tool? Sí, como cribado barato, pero nunca como única defensa. Lo dicen los propios proveedores, como Invariant Labs, que llama heurística a su detector basado en clasificador. Una inyección en la salida de una tool es texto que intenta dar órdenes al modelo, escondido en un ticket, una web o un resultado. La guía de OWASP añade que la detección debe activar un trato más estricto o una revisión humana. Las cifras publicadas van en la misma línea: ShieldMCP, un proxy que revisa llamadas y respuestas, baja el éxito de la inyección por respuesta de tool del 47 % a menos del 6 %. Lo miden sus autores, sin réplica independiente. Un estudio de la USTC (arXiv 2609.34862) usó Jev como juez sobre 5.219 trazas guardadas. Sacó un F1 medio de 77,8 frente a 74,1 del mejor juez generativo, pero perdió en dos de las cuatro colecciones. Nuestra recomendación es pasar el juez por cada respuesta como filtro y, si salta, aislar ese contenido y no encadenarlo con una tool que envíe datos fuera. Límites: sesgos, coste, latencia y cuándo no compensa En el trabajo de Zheng et al. (NeurIPS 2023), GPT-4 como juez coincidía con personas en más del 80 % de los casos, pero tendía a preferir la primera respuesta que leía, la más larga y la suya propia. En un agente de pedidos de comida en producción (arXiv 2606.10315), el juez integrado encontró menos de una cuarta parte de los problemas sistemáticos que halló la revisión humana. A nosotros no nos compensa un juez si una comprobación determinista hace lo mismo, si hay pocas tools o si una anotación ya decide. La guía completa añade lo que este extracto deja fuera: qué es un modelo de juicio y en qué se diferencia de un LLM normal, cómo elige un agente entre cientos de tools MCP y dónde falla (LiveMCPBench), cómo evaluar si el modelo usa bien tus tools, cómo montar un juez como servidor MCP con una tabla de los servidores que existen, el juez con herramientas (agent-as-a-judge) y por qué el sampling está deprecado en 2026-07-28. DesarrolloMCP: LLM como juez y MCP Si quieres aprender a construir servidores MCP desde cero, tienes el curso de DesarrolloMCP, con el nivel Básico gratis (14 lecciones, sin tarjeta), en español.
