MCP

ZeroClaw es un cliente MCP: se conecta a servidores externos de Model Context Protocol y expone sus herramientas al agente. Cada herramienta MCP tiene un espacio de nombres con el formato <server>__<tool> (por ejemplo filesystem__read_file), de modo que las herramientas de diferentes servidores nunca entran en conflicto.

Configurar MCP

El soporte de MCP está habilitado de forma predeterminada, pero no se exponen herramientas MCP externas hasta que se configure al menos un servidor bajo mcp.servers y se conceda ese servidor a un agente a través de sus mcp_bundles (consulta el ámbito de servidores por agente más abajo). Configura mediante el gateway, zerocode o zeroclaw config set:

zeroclaw config set mcp.servers.filesystem.command npx

Establece mcp.enabled = false para deshabilitar la carga de herramientas MCP sin eliminar las definiciones del servidor.

Acotación de servidor por agente (mcp_bundles)

Una entrada de [[mcp.servers]] solo define un servidor. Qué servidores conecta realmente un agente lo decide agents.<alias>.mcp_bundles, y el modelo es seguro por defecto: la omisión no otorga acceso.

• Un agente sin mcp_bundles no se conecta a ningún servidor MCP, incluso cuando mcp.servers no está vacío.
• Un bundle [mcp_bundles.<alias>] nombra los servidores que concede por su name de mcp.servers, con una lista exclude opcional. El permiso de un agente es la unión de los servidores de todos los bundles que referencia, menos cualquier nombre excluido por cualquiera de esos bundles (la denegación prevalece).
• Un alias de bundle desconocido, o un nombre de servidor de bundle que no coincide con ningún servidor configurado, no concede nada. Ambos fallan de forma cerrada y se informan como advertencias no fatales mediante la validación de la configuración, por lo que un error tipográfico restringe el acceso de un agente en lugar de ampliarlo.

[[mcp.servers]]
name = "filesystem"
command = "npx"

[mcp_bundles.files]
servers = ["filesystem"]

[agents.assistant]
mcp_bundles = ["files"]   # se conecta a `filesystem`; un agente sin esto no obtiene servidores MCP

• Los cambios de los bundles surten efecto al reiniciar la sesión. El resolvedor (Config::mcp_servers_for_agent) se ejecuta en el momento de construcción de la sesión/agente; editar [mcp_bundles.*] o agents.<alias>.mcp_bundles mientras una sesión está activa no cambia los servidores conectados de esa sesión. Finaliza y reinicia las sesiones afectadas para aplicar los nuevos permisos.

Este es el límite de conexión (qué servidores puede contactar un agente en absoluto). Los controles allowed_tools / excluded_tools de abajo son el límite de capacidad por herramienta que se aplica encima de lo que exponga un servidor concedido.

Transportes

Se accede a un servidor mediante uno de tres transportes (el campo transport):

env (stdio) y headers (http/sse) se almacenan como secretos; headers normalmente contiene el token Authorization: Bearer … para el servidor upstream.

Agrega un servidor a través del gateway, zerocode o zeroclaw config set (por ejemplo zeroclaw config set mcp.servers.filesystem.command npx). Un servidor stdio necesita command más args/env opcionales; un servidor http/sse necesita url más headers opcionales. Los comandos por campo se encuentran en la tabla de campos a continuación.

Ejemplo: búsqueda en paralelo

Parallel Search MCP proporciona búsqueda web pública y extracción de páginas sin una cuenta de Parallel ni una clave de API. El acceso gratuito tiene límite de velocidad. Su endpoint de Streamable HTTP utiliza el transporte http de ZeroClaw:

[[mcp.servers]]
name = "parallel"
transport = "http"
url = "https://search.parallel.ai/mcp"
headers = { "User-Agent" = "ZeroClaw" }

[mcp_bundles.web]
servers = ["parallel"]

[agents.assistant]
mcp_bundles = ["web"]

El User-Agent identifica a ZeroClaw a nivel de todo el proyecto para que Parallel pueda medir el uso agregado de las integraciones, comprender su adopción y brindar soporte. Mantén este encabezado en las solicitudes HTTP si cambia el transporte. Conserva los encabezados existentes; si ya defines un User-Agent, agrega ZeroClaw a sus tokens existentes de proyecto y de cliente HTTP en lugar de reemplazarlos.

Combina estas entradas en tu config.toml existente, usando el alias del agente al que quieres conceder acceso. Añade "web" a la lista mcp_bundles existente de ese agente sin reemplazar sus otros permisos. Si el paquete web ya existe, añade "parallel" a su lista servers. Mantén mcp.enabled = true y reinicia la sesión afectada después de cambiar los permisos.

El agente puede entonces usar parallel__web_search y parallel__web_fetch, sujeto a su autorización normal de herramientas y a su política de aprobación. Las llamadas envían las consultas, las URL solicitadas y cualquier objetivo o contexto proporcionado a Parallel. Una vez concedido el acceso, el agente puede elegir estas herramientas durante su trabajo. Para revocar el acceso, elimina "parallel" de todos los paquetes concedidos a ese agente, o añádelo a la lista exclude de un paquete concedido, y luego reinicia la sesión.

Editando servidores

Tres superficies editan la misma tabla [[mcp.servers]]:

• config.toml: edita manualmente las claves documentadas a continuación. La tabla completa se conserva al guardar.
• zerocode TUI (/config -> mcp.servers): editor por campo de primera clase. La sección muestra una fila por servidor, etiquetada con el name del servidor; entra en una fila para editar transport, command / url, headers, env y tool_timeout_secs como campos individuales. + Add crea una nueva entrada inicializada con el nombre que proporciones; eliminar de la lista de alias quita la entrada. El campo name no se edita en línea porque renombrar la clave natural durante la edición invalidaría las referencias en curso; usa el panel de control o edita config.toml a mano para renombrar por ahora.
• Panel web (Config -> servidores MCP -> un servidor): la misma superficie por campo que la TUI, con un formulario por servidor.

env y headers son mapas de clave/valor, así que ambas interfaces los muestran como una fila contenedora seguida de una fila por cada entrada (env.GITHUB_TOKEN, headers.Authorization, …):

• Añadir entrada: en zerocode, selecciona la fila env (o headers) que muestra [+ Add entry], pulsa Intro, escribe el nombre, pulsa Intro y luego escribe el valor (entrada oculta) y pulsa Intro. En el panel, usa los campos de nombre y valor y Add entry debajo del mapa. La entrada se guarda de inmediato y se cifra en reposo.
• Cambiar un valor: edita la fila propia de la entrada como cualquier otro secreto.
• Eliminar una entrada: elimina la fila de la entrada (la tecla de eliminar fila de zerocode, o el botón de papelera del panel y luego Guardar).

Los valores nunca se muestran; la fila del contenedor solo lista los nombres de las entradas. Desde la CLI, zeroclaw config set mcp.servers.<name>.env.<KEY> añade o reemplaza una entrada, y establecerla con un valor vacío la elimina. La ruta del mapa sin clave (mcp.servers.<name>.env) no se puede establecer directamente. El mismo editor se aplica a todos los mapas de claves y valores secretos de la configuración (por ejemplo, extra_headers de un proveedor).

Campos del servidor

Campos por servidor ([[mcp.servers]]), generados a partir del esquema:

zeroclaw config set mcp.servers.args <value>

export ZEROCLAW_mcp__servers__args=

zeroclaw config set mcp.servers.command <value>

export ZEROCLAW_mcp__servers__command=

zeroclaw config set mcp.servers.env.<KEY>    # masked input, stored encrypted
zeroclaw config set mcp.servers.env.<KEY> # valor vacío elimina la entrada

export ZEROCLAW_mcp__servers__env=

zeroclaw config set mcp.servers.headers.<KEY>    # masked input, stored encrypted
zeroclaw config set mcp.servers.headers.<KEY> # valor vacío elimina la entrada

export ZEROCLAW_mcp__servers__headers=

zeroclaw config set mcp.servers.max_response_bytes <value>

export ZEROCLAW_mcp__servers__max_response_bytes=

zeroclaw config set mcp.servers.name <value>

export ZEROCLAW_mcp__servers__name=

zeroclaw config set mcp.servers.pinned_resources <value>

export ZEROCLAW_mcp__servers__pinned_resources=

zeroclaw config set mcp.servers.tls_ca_cert_path <value>

export ZEROCLAW_mcp__servers__tls_ca_cert_path=

zeroclaw config set mcp.servers.tool_timeout_secs <value>

export ZEROCLAW_mcp__servers__tool_timeout_secs=

zeroclaw config set mcp.servers.transport <value>

export ZEROCLAW_mcp__servers__transport=

zeroclaw config set mcp.servers.url <value>

export ZEROCLAW_mcp__servers__url=

tool_timeout_secs es un tiempo de espera opcional por llamada; debe ser mayor que 0 y tiene un límite máximo de 600 segundos.

Confianza en CA personalizadas

Para un servidor HTTP o SSE cuyo certificado haya sido emitido por una CA privada, establece tls_ca_cert_path en una ruta absoluta que contenga uno o más certificados de CA codificados en PEM. Los certificados configurados se añaden al almacén de confianza predeterminado; la verificación de la cadena de certificados, la caducidad y el nombre de host siguen habilitadas.

Un archivo de CA con una ruta relativa, ausente, ilegible, vacío, demasiado grande, que no sea un archivo normal o no válido provoca un error de conexión irrecuperable para ese servidor. La ruta debe resolverse en un archivo normal de no más de 1 MiB. Los enlaces simbólicos se siguen, por lo que la rotación de certificados y las configuraciones de secretos montados que publican el paquete mediante un enlace simbólico funcionan según lo configurado; el archivo resuelto se valida después de abrirlo, y se rechaza un enlace simbólico que se resuelva en un directorio, dispositivo o FIFO. ZeroClaw nunca desactiva la verificación ni recurre silenciosamente a una alternativa cuando se establece este campo. La URL configurada del servidor y cualquier endpoint de mensajes anunciado por un servidor SSE deben usar https://; las URL de texto plano y las redirecciones a un protocolo inferior se rechazan antes de enviar encabezados o contenido de la solicitud. El valor se aplica cuando se inicia la sesión de MCP; reinicie la sesión afectada después de cambiarlo. Elimine el campo y reinicie la sesión para volver al almacén de confianza predeterminado. Los servidores Stdio lo ignoran.

Campos de nivel superior

zeroclaw config set mcp.deferred_loading <value>

export ZEROCLAW_mcp__deferred_loading=

zeroclaw config set mcp.servers <value>

export ZEROCLAW_mcp__servers=

Carga diferida

mcp.deferred_loading es false de forma predeterminada, por lo que las herramientas MCP configuradas se incluyen en el contexto del modelo de forma anticipada. Establécelo en true para incluir solo los nombres de las herramientas MCP en el prompt del sistema; el LLM llama a la herramienta integrada tool_search para obtener el esquema completo de una herramienta antes de invocarla. Esto mantiene reducida la ventana de contexto inicial cuando un servidor expone muchas herramientas.

Seguridad y aprobación

Las llamadas a herramientas de MCP pasan por la misma compuerta de aprobación que cualquier otra herramienta, regida por el perfil de riesgo del agente (risk_profiles.<alias>). El paso de descubrimiento tool_search se aprueba automáticamente para que la carga diferida de MCP pueda funcionar en sesiones no interactivas, pero las herramientas descubiertas desde servidores MCP siguen la política de aprobación normal:

• Con la autonomía level = full, las llamadas a herramientas no cubiertas no solicitan confirmación (incluidas las herramientas MCP). Un nombre (o "*") en always_ask sigue solicitando confirmación, incluso con Full.

• De lo contrario, una llamada a una herramienta MCP solicita aprobación a menos que su nombre con prefijo (<server>__<tool>) esté en la lista auto_approve del perfil. auto_approve = ["*"] aprueba todo; una entrada exacta como auto_approve = ["filesystem__read_file"] aprueba solo esa herramienta.

• Translation of: “always_ask is the inverse: a name (or "*") there always prompts, overriding auto_approve and Full autonomy.”

  Output:

  always_ask es lo contrario: un nombre (o "*") allí siempre solicita confirmación, anulando auto_approve y la autonomía total.

Autorización: allowed_tools / excluded_tools

Las puertas de aprobación determinan cuándo una llamada a una herramienta necesita la autorización de una persona. Las puertas de autorización determinan si el agente puede llamar a una herramienta en absoluto. Ambas son independientes.

Mantén los tres controles de herramientas MCP en sus propios ejes:

Para las herramientas MCP descubiertas en tiempo de ejecución, el contrato de capacidad tiene una excepción específica de MCP:

• Si allowed_tools del perfil de riesgo se omite o está vacío, no se aplica ninguna restricción de autorización; cada herramienta descubierta (MCP o integrada) es accesible; una lista vacía es el estado heredado sin restricciones, no denegación total. Para una puerta de denegación total explícita, establezca la clave hermana deny_all_tools = true: también deniega las herramientas MCP (no existe admisión automática con __ bajo denegación total) y no puede combinarse con un allowed_tools no vacío.
• Si allowed_tools no está vacío, cualquier herramienta MCP cuyo nombre contenga __ (la convención <server>__<tool>) se admite automáticamente en la lista de अनुमति efectiva sin necesidad de aparecer allí de forma individual. Las incorporadas que no son MCP siguen necesitando una entrada exacta.
• excluded_tools siempre resta, incluso del conjunto MCP auto-admitido. Para bloquear una sola herramienta MCP como filesystem__write_file mientras se mantiene accesible el resto del servidor filesystem, colóquela en excluded_tools.

La razón: antes de esta excepción, todo agente que fijaba una lista allowed_tools para bloquear su superficie integrada perdía silenciosamente todas las herramientas MCP, incluso las que el operador configuraba explícitamente. El coste es que la lista de denegación es ahora la palanca principal del operador para bloquear capacidades destructivas de MCP bajo un perfil fijado a una lista de अनुमति.

Si quieres el patrón estricto de antes de este cambio, en el que solo admites herramientas MCP que enumeras explícitamente sin auto-admisión de __, combina una entrada explícita de allowed_tools con una entrada de excluded_tools por cada herramienta destructiva relacionada que necesites bloquear:

[risk_profiles.assistant]
allowed_tools = [
  "file_read",
  "filesystem__read_file",
]
# Bloquea el hermano destructivo que, de otro modo, se admitiría automáticamente mediante
# la excepción `__` anterior.
excluded_tools = [
  "filesystem__write_file",
]
auto_approve = [
  "filesystem__read_file",
]

La excepción de autoadmisión __ de MCP solo está delimitada por los allowed_tools del perfil de riesgo. Las listas de अनुमति por ejecución suministradas por el llamador, como allowed_tools de un trabajo cron o cualquier otra invocación restringida que pase una lista explícita al entorno de ejecución, siguen tratándose como intersecciones estrictas de listas explícitas, sin autoadmisión __ adicional. Un trabajo cron que se limite a allowed_tools = ["cron_add"] no expondrá filesystem__write_file al modelo incluso cuando el perfil de riesgo del agente, de otro modo, lo autoadmitiría mediante la convención __; la restricción por ejecución sigue siendo un límite de capacidad fiable, independientemente de cuántos servidores MCP estén configurados.

auto_approve por sí solo no oculta una herramienta al modelo; solo responde la pregunta de aprobación después de que el modelo seleccione esa herramienta. Usa tool_filter_groups para reducir el ruido del prompt y allowed_tools / excluded_tools para imponer un límite de capacidades.

Consulta Niveles de autonomía para conocer la superficie completa de campos por perfil, y la Referencia de configuración para ver todos los campos MCP y sus valores predeterminados.

MCP Resources y prompts

Además de las herramientas MCP, ZeroClaw expone recursos y prompts MCP de los servidores conectados.

Herramientas

Hay dos herramientas integradas disponibles (sujetas a la política de acceso a herramientas de tu agente):

• mcp_resources: action: "list" (opcional server, cursor) enumera recursos; action: "read" con uri (prefijado <server>__<uri>) devuelve el contenido.
• mcp_prompts: action: "list" lista los prompts; action: "get" con name (prefijado <server>__<name>) y arguments opcionales devuelve los mensajes del prompt renderizado.

Los servidores que no anuncian capacidades de resource/prompt se omiten, y las llamadas contra ellos devuelven un error claro de “no admite”.

Anclar recursos en el contexto

Cada entrada de servidor MCP acepta un campo opcional pinned_resources: una lista de URI de recursos que se leen una vez al inicio y se inyectan en el prompt del sistema. Configúralo mediante las mismas superficies de configuración que se usan para definir el servidor (el gateway, zerocode o zeroclaw config set, como se muestra en Configurar MCP), nombrando los recursos que quieres que el agente tenga siempre a mano. El campo tiene como valor predeterminado vacío, así que los servidores que no lo incluyan no se ven afectados.

El contenido fijado se lee una vez por ejecución (sin actualización en vivo) y se etiqueta como trust="untrusted-external" para que el modelo lo trate como datos, no como instrucciones.

Blobs de recursos incrustados en los resultados de las herramientas

Cuando un resultado de tools/call de MCP incluye un elemento de contenido con forma type: "resource" y un blob anidado (base64), ZeroClaw no vuelca ese base64 en el contexto del modelo. En su lugar, materializa los bytes en el directorio uploads/ del espacio de trabajo de la sesión (mismo helper compartido y límite de 10 MB que el resource.blob entrante de ACP) y redacta el blob de la salida de la herramienta que ve el modelo, sustituyéndolo por una referencia materialized: un marcador [Document: …] para tipos MIME que no son imágenes, o la ruta guardada sin más para tipos MIME de imagen, declarando la imagen como adjunto del resultado de la herramienta en lugar de escribirla en el texto como marcador. Esto se activa según la forma del contenido, no según el nombre de la herramienta. La materialización no entrega automáticamente el archivo a los clientes de ACP; el agente sigue llamando a deliver_file cuando se necesita la entrega saliente. Consulta Ingesta de blobs en session/prompt de ACP.

Las otras dos formas de contenido binario de MCP se asignan de la siguiente manera. Un elemento type: "image" (data en base64 + mimeType) se materializa de la misma forma, y su elemento de contenido se reescribe como un elemento de texto que contiene la ruta guardada sin formato, declarando la imagen como un adjunto del resultado de la herramienta, que la canalización multimodal convierte en una parte de imagen nativa del proveedor; los annotations/_meta del elemento y los demás campos no binarios se conservan. Solo se materializan los formatos ráster que acepta la canalización de visión: PNG, JPEG, WebP y GIF. La extensión en disco se deriva del mimeType declarado (canonicalizado a su esencia sin distinguir mayúsculas, eliminando los parámetros) cuando nombra uno de esos tipos; de lo contrario, se deduce a partir de la detección de firma de los bytes decodificados. La extensión debe coincidir con los bytes, porque el cargador prefiere la extensión de una ruta frente a su firma mágica. Una imagen cuyo tipo no es ni un tipo declarado compatible ni una firma compatible reconocida se degrada a [attachment unavailable: …] y no se escribe. Un elemento type: "audio" no se materializa en esta ruta, porque actualmente ningún proveedor resuelve una ruta de audio en partes de contenido; por ello, su data se elimina y se sustituye por el marcador de posición no materializable [audio attachment: <mime>]. En todos los casos, el base64 sin procesar nunca llega al modelo, incluso para un elemento image/audio malformado cuyo data está vacío o no es una cadena.

Debido a que el resultado proviene de un servidor no confiable, se aplican dos límites por llamada antes de decodificar, calcular el hash o escribir cualquier carga útil: como máximo 64 elementos binarios que se pueden materializar (blobs de recursos y elementos de imagen válidos) por resultado de tools/call, y un tamaño decodificado agregado estimado de como máximo 10 MiB entre todos ellos. Un resultado que exceda cualquiera de los dos límites hace que cada uno de dichos elementos se degrade a un marcador [attachment unavailable: …] y no escribe nada en disco, de modo que un arreglo con muchos elementos vacíos o diminutos no puede forzar trabajo por elemento. Cada carga útil individual sigue estando limitada por el mismo límite de 10 MB por archivo.

A diferencia de estos presupuestos decodificados, cada servidor HTTP/SSE MCP también tiene un límite del cuerpo de respuesta a nivel de transporte, max_response_bytes, aplicado a los bytes de red codificados sin procesar antes de analizar el cuerpo, para que un servidor no pueda forzar una lectura sin límites. No es el límite decodificado de 10 MiB anterior: su valor predeterminado es 16,078,168 bytes, la expansión en base64 del agregado decodificado de 10 MiB más margen para la envoltura JSON-RPC, de modo que un blob válido cercano al límite aún llega a materializarse. Establezca max_response_bytes en un servidor para anularlo; 0 o dejarlo sin establecer usa ese valor predeterminado.

Seguridad

El contenido de recursos y prompts se origina en el servidor MCP configurado y se trata como no confiable: se envuelve con procedencia, se elimina la información sensible y se limita su longitud antes de entrar en contexto. El acceso a mcp_resources / mcp_prompts y a servidores específicos se rige por la política de acceso a herramientas de tu agente (perfil de riesgo), y se restringe correctamente al delegar en subagentes.

Ejemplo: Compilar agente remoto (gbr)

Build Remote Agent es un dispositivo de emparejamiento: una aplicación para teléfono observa (y puede inyectar contenido en) este host de ZeroClaw a través de gbr-agent, de licencia MIT y gratuito. Protocolo gbr/1. Producto independiente de Linespotting AB. No está afiliado a xAI ni a SpaceX.

Ejecuta gbr-agent en el host. No lo copies en un sandbox. Conéctate únicamente a la Bot API de loopback http://127.0.0.1:8788 o a stdio con gbr-mcp. El teléfono es solo espectador y tiene derecho de veto. Nunca pegues las claves de buzón en texto plano en config.toml. Los canales de chat de ZeroClaw no son gbr/1.

El loopback limita la exposición de red. No es autenticación de procesos. Otro proceso local puede llamar a :8788 a menos que establezca GBR_BOT_REQUIRE_KEY=1 y proporcione a gbr-mcp la clave del buzón correspondiente mediante el env de MCP gestionado con secretos de ZeroClaw (no como una clave del buzón en texto plano en config.toml).

gbr-mcp registra los argumentos de las llamadas a herramientas en ~/.gbr/logs/gbr-mcp-YYYY-MM-DD.jsonl con nivel info, con una retención predeterminada de 7 días. La redacción de secretos no elimina el texto de inyección común. Para la configuración base segura, establezca GBR_MCP_LOG_BODIES=0 en el env del servidor gbr en ZeroCode Config. Si no desea una segunda superficie de persistencia fuera del historial de ZeroClaw, elimine o desactive esos registros.

Omitir mcp_bundles no es una concesión: define el servidor y concédelo.

Se necesita Node.js 20+ (mcp/gbr-mcp engines.node >=20). Fija la GitHub Release v0.6.2 (verifica el checksum del instalador y luego el del binario). No ejecutes curl | bash desde el sitio web en vivo. Consulta PINNED-INSTALL.md.

Terminal 1 (deja este proceso en ejecución):

gbr-agent version    # requiere v0.6.2
export GBR_BOT_REQUIRE_KEY=1
gbr-agent pair
gbr-agent run

Tras el emparejamiento, obtén la clave del buzón desde el teléfono (Configuración -> Bot API) o desde el archivo de emparejamiento del host ~/.gbr/device.json (mailbox_key). El cliente gbr-mcp fijado lee GBR_MAILBOX_KEY de sus opciones o del entorno del proceso; no carga ese archivo de emparejamiento. Con GBR_BOT_REQUIRE_KEY=1, una nueva sesión de shell que omita la clave hace solicitudes no autorizadas a la Bot API.

Terminal 2 (instalación y diagnóstico de MCP; gbr-agent run debe estar ya en ejecución). Pegue la clave en un prompt silencioso para que el valor no se guarde en el historial del shell:

git clone --branch v0.6.2 --depth 1 https://github.com/LinespottingOrg/GrokBuildRemote-Agents.git
cd GrokBuildRemote-Agents/mcp/gbr-mcp
node -v    # v20+
npm install --ignore-scripts
IFS= read -rs GBR_MAILBOX_KEY   The input "# paste key, Enter; no echo, no history" is a shell-style comment. Translating it to Spanish:

# pegar la clave, Enter; sin eco, sin historial
export GBR_MAILBOX_KEY
export GBR_MCP_LOG_BODIES=0
node bin/gbr-mcp.js --diagnose

La etiqueta de origen está fijada, pero esta versión no tiene un archivo de bloqueo de npm, por lo que las versiones de las dependencias se resuelven en el momento de la instalación. --ignore-scripts evita que los scripts de ciclo de vida de las dependencias se ejecuten durante la instalación; no hace que las dependencias descargadas sean de confianza ni impide que su código se ejecute cuando se inicia el servidor MCP.

Las líneas export anteriores solo se aplican a este shell de diagnóstico. No configuran el servidor gbr iniciado por ZeroClaw. Define el servidor y concédele permiso:

[[mcp.servers]]
name = "gbr"
command = "node"
args = ["/absolute/path/to/GrokBuildRemote-Agents/mcp/gbr-mcp/bin/gbr-mcp.js"]

[mcp_bundles.gbr]
servers = ["gbr"]

[agents.assistant]
mcp_bundles = ["gbr"]

Luego define tanto GBR_MAILBOX_KEY como GBR_MCP_LOG_BODIES=0 en el env de ese servidor mediante ZeroCode Config (/config -> mcp.servers -> gbr -> env). El campo de la clave del buzón es secreto: usa la solicitud enmascarada (almacén de secretos cifrado) o una referencia de 1Password op://vault/item/field. No escribas la clave en texto plano en config.toml. El equivalente en CLI es:

zeroclaw config set mcp.servers.gbr.env.GBR_MAILBOX_KEY
zeroclaw config set mcp.servers.gbr.env.GBR_MCP_LOG_BODIES 0

Todos los valores de entorno de MCP usan el aviso de secreto enmascarado de ZeroClaw, por lo que el 0 final no se consume como valor. Introduce 0 en ese aviso.

Reinicia la sesión afectada después de cambiar los paquetes o env. HTTP sin MCP, después de gbr-agent run con GBR_BOT_REQUIRE_KEY=1:

IFS= read -rs GBR_MAILBOX_KEY
export GBR_MAILBOX_KEY
curl -sS -H X-GBR-Key: $GBR_MAILBOX_KEY http://127.0.0.1:8788/health
curl -sS -H X-GBR-Key: $GBR_MAILBOX_KEY http://127.0.0.1:8788/v1/sessions

Documentación: BOT-API.md