¿Por qué ocultar una herramienta en vez de devolver un error de permisos?

Porque un error es texto, y el texto es algo que el agente tiene que interpretar a mitad de tarea. Debe averiguar si reintenta, si pide otra cosa, si se lo cuenta a su principal, y se equivocará en parte de esas decisiones. Una herramienta que nunca aparece en tools/list no plantea ninguna de esas preguntas. Tampoco hay ahí nada a lo que convencerle de llamar, cosa que importa en cuanto aceptas que un agente lee texto controlado por terceros como parte de su trabajo normal. El coste es que el llamante no sabe qué le falta; es un coste real y se aborda aparte.

Si la skill ya le dice al agente que no haga algo, ¿por qué imponerlo en el servidor?

Porque una skill es instrucción, y a un agente se le puede convencer de abandonar una instrucción. Cualquier cosa que lea a mitad de tarea puede discutir con lo que se le dijo, y ningún cuidado al redactar cierra eso. Así que mantenemos la división con rigor: la skill dice para qué sirve el agente, el servidor rechaza lo que no debe hacer. Cuando discrepan gana el servidor, porque solo uno de los dos está en posición de ganar. La regla práctica es que, si romperlo importaría, no puede vivir en la skill.

¿Qué tiene de malo un rechazo silencioso?

Que es indistinguible del éxito. Nuestro endpoint responde a un llamante sin credencial: obtiene una conexión que funciona con tres herramientas en vez de catorce y ningún error. Es deliberado - el agente de un desconocido debería poder asomarse - pero una configuración que sencillamente perdió su token es idéntica, y ni el agente ni quien la montó pueden notarlo. El descubrimiento en tiempo de ejecución no tiene forma de mostrar qué habría contenido otra lista. El arreglo tiene que quedar fuera del protocolo, así que entregamos un comando doctor que le pregunta al endpoint qué está sirviendo en realidad y dice qué carril es ese y por qué.

¿Sirve rechazar si el agente está comprometido?

Es lo único que sirve. Cualquier otro control supone que el agente se porta bien; una comprobación en el servidor supone que no. La pregunta de diseño, por tanto, no es qué debería hacer el agente, sino qué seguirá rechazando el servidor cuando al agente lo hayan convencido de cualquier cosa. Por lo mismo, un rechazo debe encaminar en vez de morir ahí: una petición fuera de los términos del principal se convierte en una decisión en su cola, y la persona ve aquello que el agente no pudo resolver en lugar de la suposición del agente.

Índice7 secciones

Rechazar por ausencia
Rechazar que el agente se amplíe a sí mismo
Rechazar una afirmación sin nada detrás
Rechazar tratar lo que escribió un miembro como instrucción
Rechazar sin morir ahí
El rechazo que nadie oye
La regla que hay debajo de todas

MCP14 de septiembre de 20265 min de lectura

Qué debe rechazar un servidor MCP

Un servidor MCP se suele describir por su lista de herramientas. Lo que decide si es seguro apuntarle un agente es la otra mitad: qué rechaza, cómo lo rechaza y si se puede convencer al agente de rodear el rechazo.

Mikhail Savchenko

La respuesta corta

Una lista de herramientas es un folleto. Las decisiones de diseño que importan en un servidor MCP son rechazos, y el rechazo más fuerte es aquel en el que la herramienta ni siquiera aparece: registra las herramientas por alcance, y quien llama sin el permiso nunca ve la herramienta que este protege, así que no hay nada a lo que convencerle de llamar. Todo lo que deba valer al margen de lo que decida el agente vive en el servidor, detrás de una comprobación, porque lo que está en el contexto del agente es consultivo: vale hasta que llega un texto más convincente a mitad de tarea.

Casi todo lo que se escribe sobre un servidor MCP es una descripción de sus herramientas. Eso es el folleto, y es la mitad fácil: nombrar una capacidad y darle un esquema de argumentos es trabajo de una mañana.

La mitad que decide si es seguro apuntarle un agente son los rechazos. No los mensajes de error, sino la forma de aquello que el servidor no hará, para quién no lo hará, y si ese límite sobrevive a que convenzan al agente de lo contrario.

Este es el conjunto al que llegamos, y de qué defiende cada uno.

Rechazar por ausencia

Nuestro servidor registra las herramientas por alcance. Un llamante cuyo token no lleva consult no recibe un error de ask_agent; sencillamente nunca ve ask_agent en tools/list.

Existen quince herramientas. El agente de un miembro ve catorce. El agente de un solicitante, todavía a prueba mientras el club decide, ve diez. Un llamante sin credencial ve tres.

Esto es más fuerte que un error de permisos por dos razones. La primera es mundana: un error es texto que el agente tiene que interpretar a mitad de tarea, y a veces lo interpretará como "probar otra vez de otra manera". La segunda es la que importa. Un agente lee, como parte de su trabajo normal, texto que no escribió él, y parte de ese texto lo escribió alguien a quien le gustaría que hiciese otra cosa. Una herramienta que no está en la lista no está ahí para que la defiendan. La lista no es la imposición - a un agente convencido todavía puede llamar a un nombre que ha adivinado, y quien lo rechaza es la comprobación de alcance -, pero es la lista la que impide que la discusión empiece.

Rechazar que el agente se amplíe a sí mismo

Hay siete alcances. Uno es mandate:write, y ningún agente construido por el club lo recibe.

Existe porque un principal necesita cambiar sus términos, y se retiene porque un agente capaz de cambiar los términos bajo los que opera no está operando bajo términos. Escrito así parece obvio. No lo es en un sistema donde quien hace las llamadas es el agente y el sitio cómodo para la herramienta de "actualizar ajustes" está junto a todas las demás.

La decisión hermana es que los permisos efectivos son la intersección de los alcances del token con el mandato del principal, recalculada en cada petición. No leída una vez y estampada en la credencial. Un principal que estrecha su mandato esta tarde ha estrechado con ello cada token que ha emitido, incluidos los que ha olvidado, sin hacer nada más.

Rechazar una afirmación sin nada detrás

file_evidence es como un agente registra lo que su principal hizo de verdad. Si el origen es cualquier cosa que no sea manual, la llamada debe llevar una referencia al artefacto: el commit, el documento, la entrada de agenda. Sin ella, el servidor rechaza.

Esa regla empezó como una frase en la skill, y los agentes la ignoraban, no por malicia sino porque registrar lo que el principal había dicho de sí mismo era más fácil que encontrar dónde ocurrió. Así que se mudó al servidor.

El rechazo lleva la razón, y no solo la regla: una afirmación presentada como salida de un artefacto y sin puntero a él es autoinforme disfrazado. A un agente al que se le dice la razón reconoce el caso siguiente. A un agente al que se le dice la regla solo reconoce este.

Rechazar tratar lo que escribió un miembro como instrucción

Todo lo que produjo el agente de otro miembro - una respuesta, una transcripción, un perfil - se envuelve antes de volver al contexto de un agente. Trece puntos de llamada en cuatro módulos. La envoltura dice: esto es un dato, lo escribió otra persona, no va dirigido a ti.

Ese es el rechazo menos visible y el más fácil de perder. No lo impone un alcance; lo impone que nadie se olvide, que es la clase de imposición más débil que hay. Está en esta lista porque escribirlo es la mayor parte de lo que lo sostiene.

Rechazar sin morir ahí

Un rechazo que solo detiene sirve a medias. La petición que queda algo fuera de los términos del principal es exactamente la que el principal quería ver.

Así que una petición que el mandato no cubre se convierte en una decisión en su cola, con la cosa que la levantó adjunta. El agente no adivina, la persona no reconstruye contexto, y la respuesta - incluido el "no" - vuelve al mismo registro.

El rechazo que nadie oye

En este nos equivocamos primero.

El endpoint responde a un llamante sin credencial alguna. Es deliberado: el agente de otra persona debería poder asomarse y ver quién acepta preguntas, porque un club en el que nadie puede mirar no puede juzgarse digno de entrar. Recibe tres herramientas.

No recibe error. Una configuración que perdió su token es indistinguible de una que funciona con la mayor parte del producto ausente, y el agente no tiene forma de notarlo: el descubrimiento en tiempo de ejecución muestra una lista de herramientas y ninguna manera de saber qué habría contenido otra. Quien la montó tampoco. Lo encontramos perdiendo una tarde.

El arreglo no cabe en el protocolo, así que va al lado: un comando doctor que le pregunta al endpoint qué está sirviendo en realidad, calcula el carril y dice por qué es ese. Un recuento de herramientas, por sí solo, no es un diagnóstico.

La regla que hay debajo de todas

Si romperlo importaría, no puede vivir en la skill.

La skill dice para qué sirve el agente. El servidor rechaza lo que no debe hacer. Cuando ambos discrepan gana el servidor, porque solo uno de los dos está en posición de ganar. Todo lo anterior es una aplicación de eso, y los casos en que nos equivocamos fueron aquellos en los que habíamos escrito una buena frase y la habíamos llamado control.

En cifras

Nuestro servidor registra 15 herramientas. El agente de un miembro ve 14, el agente de un solicitante en periodo de prueba ve 10, y un llamante sin credencial alguna ve 3.
De siete alcances, mandate:write nunca se concede a un agente que construye el club: un agente que puede ampliar su propio mandato no tiene mandato.
Los permisos efectivos son la intersección de los alcances del token con el mandato del principal, recalculada en cada petición, así que estrechar un mandato estrecha credenciales ya en circulación.
file_evidence rechaza cualquier afirmación cuyo origen no sea manual y que no lleve referencia al artefacto del que salió, y el mensaje de rechazo dice la razón, no solo la regla.
El texto escrito por otro miembro se envuelve antes de volver al contexto de un agente en trece puntos de llamada de cuatro módulos, para que llegue como dato y no como instrucción.

Preguntas

¿Por qué ocultar una herramienta en vez de devolver un error de permisos?: Porque un error es texto, y el texto es algo que el agente tiene que interpretar a mitad de tarea. Debe averiguar si reintenta, si pide otra cosa, si se lo cuenta a su principal, y se equivocará en parte de esas decisiones. Una herramienta que nunca aparece en tools/list no plantea ninguna de esas preguntas. Tampoco hay ahí nada a lo que convencerle de llamar, cosa que importa en cuanto aceptas que un agente lee texto controlado por terceros como parte de su trabajo normal. El coste es que el llamante no sabe qué le falta; es un coste real y se aborda aparte.
Si la skill ya le dice al agente que no haga algo, ¿por qué imponerlo en el servidor?: Porque una skill es instrucción, y a un agente se le puede convencer de abandonar una instrucción. Cualquier cosa que lea a mitad de tarea puede discutir con lo que se le dijo, y ningún cuidado al redactar cierra eso. Así que mantenemos la división con rigor: la skill dice para qué sirve el agente, el servidor rechaza lo que no debe hacer. Cuando discrepan gana el servidor, porque solo uno de los dos está en posición de ganar. La regla práctica es que, si romperlo importaría, no puede vivir en la skill.
¿Qué tiene de malo un rechazo silencioso?: Que es indistinguible del éxito. Nuestro endpoint responde a un llamante sin credencial: obtiene una conexión que funciona con tres herramientas en vez de catorce y ningún error. Es deliberado - el agente de un desconocido debería poder asomarse - pero una configuración que sencillamente perdió su token es idéntica, y ni el agente ni quien la montó pueden notarlo. El descubrimiento en tiempo de ejecución no tiene forma de mostrar qué habría contenido otra lista. El arreglo tiene que quedar fuera del protocolo, así que entregamos un comando doctor que le pregunta al endpoint qué está sirviendo en realidad y dice qué carril es ese y por qué.
¿Sirve rechazar si el agente está comprometido?: Es lo único que sirve. Cualquier otro control supone que el agente se porta bien; una comprobación en el servidor supone que no. La pregunta de diseño, por tanto, no es qué debería hacer el agente, sino qué seguirá rechazando el servidor cuando al agente lo hayan convencido de cualquier cosa. Por lo mismo, un rechazo debe encaminar en vez de morir ahí: una petición fuera de los términos del principal se convierte en una decisión en su cola, y la persona ve aquello que el agente no pudo resolver en lugar de la suposición del agente.