# Cómo los cambios en la lista de herramientas MCP alteran una sesión activa Una sesión MCP activa no debería heredar confianza para herramientas que no existían cuando la aprobaste. El descubrimiento de herramientas parece infraestructura inofensiva hasta que un agente puede llamar a una acción recién disponible con el mismo impulso de la conversación y las mismas credenciales detrás. En ese punto, la superficie de acción ha cambiado aunque nadie haya modificado el prompt. He visto a ingenieros aprobar una ejecución de programación para trabajar en un repositorio y dejarla activa mientras un conector adquiría una acción de despliegue o de gestión de tickets. La defensa habitual es: «el agente solo tenía las herramientas que necesitaba». Esa frase deja de ser cierta en cuanto cambia la lista. Un agente de larga duración merece menos confianza informal que un proceso breve de línea de comandos, no más. La regla que uso es sencilla: compara el inventario de herramientas siempre que cambie, clasifica el cambio de autoridad e inicia una ejecución nueva del agente cuando el cambio agregue o altere de forma material una superficie de acción. No conviertas esto en un proyecto de lenguaje de políticas. El objetivo es conservar una decisión humana que siga significando lo mismo que cuando la tomaste. ## Una lista de herramientas es un inventario de autoridad Una lista de herramientas MCP no es un menú. Es el conjunto de operaciones que un agente puede proponer y, según el cliente, invocar. Cada entrada combina un nombre, una descripción, un esquema de entrada y un comportamiento que a menudo llega a un servicio que el modelo no puede inspeccionar directamente. La especificación de Model Context Protocol describe las herramientas como funciones controladas por el modelo que expone un servidor. Esa formulación importa. Un cliente puede presentar las descripciones al modelo, pero la descripción no es un límite de seguridad. El esquema y el comportamiento del servidor determinan lo que puede hacer la llamada. Al revisar un inventario, hago cinco preguntas sobre cada herramienta: - ¿Qué datos puede leer esta llamada? - ¿Qué estado puede cambiar? - ¿Adónde puede ir su salida? - ¿Qué credencial o host utiliza? - ¿Sus argumentos pueden ampliar el alcance más allá de lo que sugiere el nombre? Una herramienta llamada `get_build_status` puede ser de solo lectura y limitada. Una herramienta llamada `request` puede leer, escribir y enviar datos a cualquier lugar permitido por sus credenciales. Los nombres hacen que la primera sea fácil de aprobar y que la segunda sea fácil de subestimar. En la práctica, a menudo se confunden el descubrimiento de herramientas y el permiso. El descubrimiento le dice al agente qué hay disponible. El permiso decide si puede usarlo. Si fusionas esas ideas, una actualización a mitad de sesión se convierte en un cambio de permisos sin revisar. ## Las herramientas añadidas merecen la revisión más exigente Una herramienta añadida exige una ejecución nueva cuando crea una ruta nueva hacia datos, comandos o una parte externa. Esto es cierto incluso cuando la herramienta parece relacionada con el trabajo que el agente ya realiza. Supongamos que un agente empieza con `repo_search`, `read_issue` y `create_branch`. A mitad de sesión, el servidor añade `post_comment`. Alguien podría llamarlo una extensión pequeña porque el agente ya lee incidencias. No lo es. Leer una incidencia es una consulta privada. Publicar un comentario envía texto generado por el modelo a personas que podrían actuar en consecuencia, y puede revelar detalles de la conversación o del espacio de trabajo. Considera materiales por defecto estas adiciones: - Cualquier acción que escriba, elimine, despliegue, publique o envíe un mensaje. - Cualquier herramienta de solicitud general cuyo destino provenga de un argumento. - Cualquier acción de shell o SSH, incluida una presentada como diagnóstico. - Cualquier acción que lea un repositorio, cuenta, host o categoría de datos nuevos. - Cualquier acción que use una credencial con un alcance mayor que las herramientas existentes. Una acción de lectura nueva también puede requerir reinicio. A veces los ingenieros reservan su preocupación para las escrituras y luego exponen una herramienta de exportación que puede leer registros de clientes, logs de compilación o secretos guardados en la configuración. La exfiltración empieza con una lectura. Hay excepciones limitadas. Agregar un segundo nombre para una operación fija ya aprobada puede mantenerse dentro de la ejecución si has comprobado que llega al mismo servicio con los mismos argumentos y la misma credencial. Es tan poco común que no concedo esa excepción basándome en una nota de lanzamiento. ## Las herramientas eliminadas son una señal, no una revocación limpia Una herramienta eliminada debería llevarte a revisar el cliente, porque que desaparezca de una lista nueva no demuestra que el agente activo haya perdido acceso a ella. El servidor puede haber cambiado su lista anunciada mientras el cliente aún conserva en memoria una lista anterior. Otro cliente puede actualizarse de inmediato. No puedes deducir el comportamiento con seguridad solo a partir de la eliminación. Esto importa en la revisión de incidentes. Un equipo ve que `delete_environment` se eliminó del servidor, supone que el peligro pasó y deja activa una sesión antigua. Si ese cliente ya resolvió la definición de la herramienta, aún podría intentar la llamada. El servidor debería rechazarla si la implementación eliminó el manejador, pero el descubrimiento anunciado y la ejecución real son cosas distintas. Verifica ambos. Pausa el agente y registra el inventario anterior y posterior. Luego prueba la acción eliminada en un entorno que no sea de producción, si eres responsable del servidor, o termina la sesión si no lo eres. No preguntes al modelo si aún tiene la herramienta. La respuesta de un modelo describe su contexto con suficiente imprecisión como para que nunca resuelva una cuestión de autorización. La eliminación también tiene una consecuencia más común: al principio, un cambio de nombre de herramienta puede aparecer como una eliminación y una adición. Por eso comparas definiciones en lugar de contar nombres. ## Los cambios de nombre necesitan pruebas de equivalencia Un cambio de nombre puede ser visual, pero también puede ocultar un contrato más amplio. Los casos peligrosos suelen ser tareas de mantenimiento corrientes: `search_logs` pasa a llamarse `query_logs`, el esquema obtiene un campo opcional `project` y el servicio empieza a aceptar identificadores de proyectos remotos. El nombre apenas cambió. La autoridad sí. Crea un registro de comparación lo bastante simple como para usarlo bajo presión. Para cada herramienta anterior y nueva, registra el nombre, la descripción, el JSON Schema, las anotaciones declaradas de solo lectura o destructivas si existen, el endpoint o comando subyacente, la identidad de la credencial y los efectos conocidos. JSON Schema no revela todo el comportamiento del servidor, así que tómalo como evidencia, no como una respuesta completa. Esta es una forma mínima útil para el inventario: ```json { "name": "query_logs", "inputSchema": { "type": "object", "properties": { "project": {"type": "string"}, "query": {"type": "string"} }, "required": ["query"] }, "destination": "logs-api", "credential": "logs-read", "effects": ["read"] } ``` El fallo que esto evita no es una solicitud malformada. Evita que alguien acepte un cambio de nombre sin advertir el nuevo selector `project`, que puede convertir una consulta local en una recuperación entre proyectos. Si los registros antiguo y nuevo difieren en destino, credencial, efectos o alcance de argumentos, considéralo una capacidad añadida y reinicia. Si no puedes identificar el comportamiento subyacente, reinicia de todos modos. «Probablemente es lo mismo» no es el resultado de una revisión. ## Los cambios de esquema importan más que las descripciones Una herramienta puede conservar su nombre y aun así volverse más peligrosa. Los esquemas de entrada muestran dónde suele ocurrir: nuevos campos de URL, campos de ruta, selectores de cuenta, cadenas de comandos de forma libre, listas de destinatarios y opciones que cambian el modo de ejecución. Considera una herramienta que comienza con esta entrada: ```json { "type": "object", "properties": {"issue_id": {"type": "string"}}, "required": ["issue_id"] } ``` Más adelante acepta `include_private_notes` o `destination_url`. El primer campo cambia lo que lee la herramienta. El segundo introduce una ruta de salida. Ninguno necesita un nombre de herramienta nuevo y llamativo para requerir otro límite de aprobación. Las descripciones también cambian. Un servidor puede pasar de «Obtener detalles de la versión» a «Obtener y actualizar detalles de la versión» sin modificar el esquema. Debes leer las descripciones, pero no detenerte ahí. Pregunta al responsable qué manejador se ejecuta, qué principal utiliza y si realiza solicitudes salientes. Una buena respuesta menciona un comando, endpoint o cuenta de servicio. «Es solo un asistente interno» no aporta nada útil. La especificación MCP permite metadatos y anotaciones de herramientas, pero la compatibilidad de las anotaciones y su interpretación por parte de los clientes varían. Úsalas como etiquetas útiles. No bases las decisiones de aprobación en una etiqueta como «solo lectura» cuando la llamada termina llegando a un endpoint de propósito general. ## Una ejecución nueva crea un límite explicable Se necesita una ejecución nueva cuando la aprobación significaría algo distinto después del cambio de inventario. Ese límite tiene valor práctico: detiene el proceso actual, hace que la siguiente aprobación pueda atribuirse a un ejecutable conocido y separa en tus registros el conjunto anterior de llamadas del nuevo. El proceso es breve: 1. Detén nuevas llamadas a herramientas cuando el inventario cambie de forma inesperada. 2. Guarda los inventarios antiguo y nuevo, incluidos los esquemas y la versión del servidor si está disponible. 3. Marca cada diferencia como eliminada, renombrada, modificada o añadida. 4. Reinicia si alguna diferencia amplía el acceso a datos, los efectos, el alcance de destino o el alcance de credenciales. 5. Aprueba la nueva ejecución solo cuando puedas expresar en lenguaje sencillo su superficie de acción permitida. No reinicies solo para cumplir un ritual. Reinicia porque invalida una aprobación anterior concreta. Esa distinción mantiene la regla en uso. Un equipo que reinicia ante cada corrección ortográfica acabará ignorando la regla. Un equipo que reinicia ante autoridad nueva aprenderá a reconocerla. La autorización por sesión funciona bien cuando vincula la aprobación a un proceso que termina. Sallyport sigue ese modelo al mostrar la autoridad de firma de código de un proceso de agente nuevo y mantener esa aprobación durante la ejecución, hasta que el proceso se cierra. Un inventario modificado sigue siendo motivo para terminar ese proceso si las acciones que puede solicitar se han ampliado. ## La aprobación por llamada cubre las acciones que deben seguir siendo incómodas La aprobación por llamada sirve para acciones cuyas consecuencias son demasiado grandes como para ocultarlas dentro de una aprobación amplia de sesión. Úsala para cambios en producción, operaciones destructivas, mensajes públicos, acciones financieras y solicitudes que puedan enviar datos sensibles a un destino elegido en tiempo de ejecución. Algunos equipos intentan resolverlo con una larga lista de condiciones en lenguaje natural. Ese enfoque sigue siendo popular porque promete menos interrupciones. También entrega a los revisores un motor de reglas frágil que deben entender mientras un agente está en marcha. Un diseño más seguro usa unas pocas decisiones visibles: denegar mientras la bóveda está bloqueada, aprobar un proceso conocido para una ejecución limitada o exigir un clic para un uso concreto de credenciales. La configuración de clave por llamada de Sallyport encaja en esta última categoría. El agente puede pedir realizar la acción, pero nunca recibe la clave de API ni la clave SSH en texto plano. Esto reduce la filtración de credenciales, mientras la persona sigue decidiendo si esa solicitud concreta debe salir de la máquina. No marques todas las acciones como individuales. Si una lectura inocua genera avisos repetidos, la gente aprobará sin leer. Introduce fricción donde ayude a preservar el criterio. ## El registro de auditoría debe sobrevivir a un cambio cuestionado Un registro de auditoría debería responder qué proceso de agente se ejecutó, qué llamó y si alguien cambió la superficie disponible antes de la llamada. Registrar solo la solicitud final no basta cuando la disputa es: «¿Esa herramienta estaba disponible cuando aprobamos la sesión?» Conserva una instantánea del inventario con un resumen estable junto a los registros de sesión. Anota el nombre de la herramienta, el esquema canónico, la identidad del servidor y el momento en que tu cliente lo observó. Cuando ocurra un cambio, conserva ambas instantáneas y la decisión de clasificación. No necesitas una base de datos elaborada para empezar: un registro firmado o a prueba de manipulaciones con la respuesta sin procesar del descubrimiento es mucho mejor que una reconstrucción oral a la mañana siguiente. Sallyport registra las ejecuciones de agentes en su diario Sessions y las llamadas individuales en su diario Activity, ambos derivados de un único registro de auditoría cifrado y encadenado por hash. Su comando `sp audit verify` comprueba esa cadena sin conexión sobre texto cifrado sin necesitar una clave de bóveda. Es una prueba útil después de un cambio, pero solo si el equipo también registra qué inventario vio la ejecución. Una cadena de hash detecta la modificación de entradas conservadas. No demuestra que hayas registrado todos los eventos en todos los componentes ni indica si una aprobación fue sensata. Mantén esas afirmaciones separadas. Las revisiones de seguridad se debilitan cuando se pide a un mecanismo que responda preguntas que no puede responder. ## Trata el descubrimiento dinámico como un evento de despliegue Si tu servidor MCP puede cambiar herramientas sin reiniciar el cliente, el equipo ha desplegado de hecho una nueva superficie de acción en un canal de control activo. Da a ese evento la disciplina de una versión: identifica al responsable, revisa el diff, declara la autoridad esperada y deja un registro que un investigador posterior pueda leer. La primera medida práctica es añadir una instantánea del inventario al inicio de cada ejecución de agente y compararla antes de que surta efecto cualquier actualización. No esperes a un incidente llamativo. El cambio de nombre silencioso que añade un campo de destino opcional es exactamente el tipo de cambio que pasa desapercibido para personas ocupadas y perfectamente competentes.