Qué registrar en cada llamada a una herramienta MCP

El 8 de junio de 2026, Anthropic dio a los propietarios de conectores del directorio de Claude un panel. Muestra los usuarios activos, el total de llamadas a herramientas y la posición en el directorio. Muestra “la puntuación de salud, las tasas de error y la latencia de un vistazo, con un desglose de errores por herramienta para localizar exactamente qué está fallando”.

Un año antes, Alex Volkov, de Weights & Biases, había descrito el mismo problema desde el otro extremo. En cuanto su agente llamaba a herramientas a través de MCP, “toda esa observabilidad a la que estoy acostumbrado cuando mi propio código se ejecuta de principio a fin se ha quedado un poco a oscuras”. Su compañero de charla, Benjamin Eckel, de Dylibso, mostró por qué. Un servidor MCP remoto “nos aparece en la traza como un único span de servicio”, porque se ejecuta fuera del control de quien llama.

Las dos vistas están fuera del servidor. El cliente ve un span opaco. El directorio ve totales. Ninguno vio qué se le pidió al servidor, qué rechazó y qué tocó. Solo lo vio el servidor, así que solo el servidor puede anotarlo.

Esto es lo que anotan los servidores MCP de Tajo, leído del código que los ejecuta y descrito en la documentación. Qué es un servidor MCP cubre el protocolo. Aquí se trata de la fila.

Una fila por llamada

Un panel es la vista del capitán de puerto: barcos que entran, barcos que salen, cuáles llegaron tarde. El registro de solicitudes es el cuaderno de bitácora del propio barco, escrito a bordo y en el momento.

Cada tools/call en el servidor del espacio de trabajo de Tajo y en cada servidor de conector termina en una fila. La fila se escribe después de construir la respuesta, sea cual sea esa respuesta. Una llamada rechazada porque la clave no puede escribir, o porque el endpoint es de solo lectura, recibe una fila como cualquier otra. También la recibe una llamada a una herramienta que no existe.

Esto es lo que contiene la fila, y lo que se niega a contener.

Campo	Se guarda	No se guarda
Quién	El ID de la clave de API que llamó. Un token de un inicio de sesión con OAuth también es una clave.	El secreto de la clave o su prefijo.
Dónde	El servidor del espacio de trabajo o un servidor de conector, con su conector y su perfil.
Herramienta	El nombre, cuando el servidor tiene una herramienta con ese nombre.	Cualquier otro nombre que envíe el cliente: se almacena como (unknown).
Efecto	read, write, send o destructive: el efecto más grave que podría tener la llamada.
Resultado	ok, o un código de error corto en snake_case como unknown_tool.	El texto de los errores: todo lo que no es un código se almacena como tool_error.
Duración y tamaño	Los milisegundos desde la llegada hasta la respuesta, y los bytes que recibió quien llamó.
ID de traza	El ID de la solicitud, tomado de una cabecera x-request-id, x-trace-id o W3C traceparent, o uno nuevo si no la hay.	Un valor de cabecera que no sea hexadecimal ni un UUID.
Registros	Hasta 20 ID de registros que la llamada nombró o produjo: un contacto, un mensaje, una aprobación.	Los registros en sí.
Cuerpos	Los argumentos y la respuesta, limpios, 4 KB como máximo cada uno.	Los secretos, el texto libre y los datos personales que se enumeran más abajo.

Tres de esas negativas tienen que ver con el cliente, no con los datos. Un nombre de herramienta, un código de error y un ID de traza llegan todos de fuera. Cada uno se guarda solo en una forma de la que el servidor puede responder. Un registro que almacena cualquier cosa que haya enviado quien llama puede llenarse de cualquier cosa, incluida la dirección de correo de un cliente en la columna del nombre de la herramienta.

La pregunta abierta de Benjamin Eckel al final de la charla era cómo sabe un colector “que es una llamada a una herramienta MCP que tiene un error”. En un mismo servidor, la respuesta es una columna. ok es false, y el código dice qué error.

Los argumentos: una regla que invertimos

La objeción es justa, y es nuestra. Registra los argumentos y habrás construido una segunda copia de los datos de tus clientes, fuera del alcance de cualquier solicitud de borrado. Hasta el 18 de octubre de 2026 esa era nuestra propia regla. El registro no guardaba ni los argumentos ni el cuerpo del resultado, porque ambos pueden contener datos personales.

Era el compromiso equivocado. Un registro de solicitudes que no puede mostrar qué se envió y qué volvió no puede responder a la única pregunta para la que existe: ¿por qué falló la llamada de mi agente?

Así que los cuerpos se guardan, y el motivo por el que no se guardaban se atiende de otra forma. Cada cuerpo pasa por una pasada determinista antes de entrar en la cola.

• Ningún secreto sobrevive. Un campo cuyo nombre indica token, contraseña, secreto, firma, cookie, sesión o una veintena de palabras parecidas conserva solo [secret]. Lo mismo ocurre con un valor que tenga una forma conocida de credencial, aparezca donde aparezca. Eso abarca tokens bearer, JWT, claves privadas, URL con contraseña y cualquier secuencia opaca de 40 o más caracteres de clave.
• La prosa no se guarda en absoluto. Un campo llamado html, text, body, markdown o content conserva solo [redacted]. La prosa contiene nombres y direcciones postales que ningún patrón encuentra.
• Los datos personales se enmascaran para siempre. Un campo cuyo nombre indica un dato personal, como un correo, un teléfono, un nombre, una dirección o una nota, conserva solo [redacted]. Una dirección de correo, un número de teléfono, una tarjeta o un IBAN dentro de cualquier otra cadena se enmascara.
• Los cuerpos se mantienen pequeños. Las cadenas se cortan en 512 caracteres, las listas en 20 elementos, los objetos en 50 claves y el anidamiento en 6 niveles. El cuerpo completo se corta en 4 KB y se marca como truncado.

Dos tipos de llamada guardan menos. Los contactos que el chat de una persona trajo desde otra aplicación se registran como una marca y un recuento, nunca como un cuerpo. Una llamada que lee el registro no guarda ninguna respuesta, ya que la respuesta solo serían otras filas del registro.

Ahora, el coste. El enmascaramiento es permanente, no un cifrado con una clave que alguien tiene. El registro no puede mostrarte la dirección de correo que rebotó. Te muestra el ID del contacto, y el contacto, bajo sus propias reglas, está a una llamada de distancia. El registro queda fuera del barrido de borrado del espacio de trabajo, y por eso el enmascaramiento no puede esperar a uno.

Por qué el registro no es la pista de auditoría

Tajo ya tiene un registro de auditoría de solo inserción. Cada fila lleva un hash de la fila anterior, así que una edición en cualquier punto rompe la cadena. ¿Por qué no escribir ahí las llamadas a herramientas?

Porque la cadena tiene un precio. Cada inserción toma un bloqueo por espacio de trabajo y lee la fila anterior para extender la cadena. Escribir ahí cada lectura pondría en fila las llamadas de un espacio de trabajo detrás de un único bloqueo. También enterraría bajo miles de lecturas los cambios de estado que el registro de auditoría existe para mostrar.

Así que los dos registros se reparten las preguntas. El registro de solicitudes dice qué pidió un agente y qué pasó, durante 30 días. El registro de auditoría dice qué cambió, quién lo permitió y si alguien ha editado el registro desde entonces.

Las aprobaciones están del lado de la auditoría. En los perfiles de conector de Tajo, una herramienta propose prepara una acción declarada y una herramienta apply la ejecuta una vez aprobada. Nada llega al proveedor hasta que la propuesta se aprueba, por una persona o por una regla que el espacio de trabajo activó. La fila de la llamada propose nombra, entre sus registros, la aprobación que creó. La aprobación en sí está vinculada a un digest SHA-256 de la entrada exacta. Una aprobación cubre la entrada exacta que viste: cambia un campo y deja de coincidir. Cuando la escritura se completa, su fila de auditoría guarda el digest de la entrada y un digest de la respuesta del proveedor, nunca los valores de la respuesta.

Lo que cuesta la fila

Una fila es una escritura en la base de datos, y una escritura tiene un commit. Hasta el 8 de octubre de 2026, cada llamada esperaba su propio commit antes de la respuesta, unos 2,6 ms en nuestro host. Para un cliente, eso era una cuarta parte de una llamada pequeña a una herramienta.

Ahora la fila se construye cuando termina la llamada y se pone en cola. Un flush escribe la cola como máximo 100 ms después, una transacción por espacio de trabajo, así que muchas llamadas comparten un mismo commit. Nada de una fila cambia, tampoco su marca de tiempo. Si hay 5.000 filas en espera, la siguiente llamada espera al flush en lugar de descartar una fila.

El registro nunca hace fallar una llamada. Una escritura que falla se reintenta fila por fila, y luego se registra y se descarta. Lo que pierde una terminación forzosa del proceso es lo que estuviera en la cola: como máximo los últimos 100 ms de llamadas.

Volver a leerlo

logs.list devuelve las llamadas del espacio de trabajo, de la más reciente a la más antigua, sin cuerpos. Filtra por tiempo, por resultado o estado HTTP, por origen (MCP o la API REST, que comparte la tabla) y por clave de API. Pagina de 50 en 50 por defecto, hasta 100. logs.get devuelve una llamada con el nombre actual de la clave, su estado, su duración, la solicitud y la respuesta limpias, y los registros que tocó.

Ambos leen solo el espacio de trabajo de quien llama. Un ID de fila de otro espacio de trabajo no se encuentra.

Un error de herramienta lleva el ID de la solicitud. Cuando el servidor creó ese ID, o llegó en hexadecimal o como UUID, es el ID de traza de la fila. Un agente que recibió un error puede pasarle a una persona el único valor que identifica la llamada.

Lo que está construido y lo que no

Construido, en el momento de escribir esto:

• Una fila por cada tools/call en el servidor del espacio de trabajo y en cada servidor de conector, incluidas las llamadas rechazadas y las desconocidas.
• ID de clave, servidor, conector, perfil, herramienta, efecto, resultado, duración, tamaño del resultado, ID de traza y hasta 20 registros tocados.
• Argumentos y respuestas limpios, 4 KB como máximo cada uno.
• logs.list y logs.get, limitados al espacio de trabajo, con 30 días de conservación.
• Aprobaciones vinculadas a un digest de la entrada, y escrituras aplicadas registradas con digests de entrada y salida en el registro de auditoría encadenado por hashes.

No construido, y conviene saberlo antes de confiar en ello:

• No hay puntuación de salud, ni gráfico por herramienta, ni alerta cuando sube la tasa de errores. Existe un resumen por herramienta de llamadas, errores y duraciones más lentas para los operadores de Tajo, no en ninguna superficie que tú puedas abrir.
• logs.list no puede filtrar por nombre de herramienta ni por ID de traza. Para encontrar la fila detrás de un ID de solicitud, acota por tiempo y por clave.
• Las filas no se exportan a un sistema de trazas que gestiones tú. El ID de traza se lee solo de las cabeceras HTTP, no del campo _meta de MCP que la charla usaba para transportar el contexto de traza.
• A los 30 días, una fila se elimina. No hay archivo ni exportación.
• Lo que se enmascaró no se puede recuperar desde el registro.
• Una terminación forzosa puede perder los últimos 100 ms de filas.

La charla terminó diciendo que la observabilidad en MCP “no está distribuida de forma uniforme”. Un panel situado más abajo no puede arreglar eso, y tampoco una traza que se detiene en la puerta del servidor. Una sincronización que falla necesita su propio registro; también lo necesita cada llamada que pidió una.

El servidor vio la llamada. Nadie más la vio. Anótalo ahí.