Un agente de IA puede orquestar la colocación de una credencial sin recibir nunca el valor de la credencial, mientras que una interfaz controlada por un humano autoriza de forma independiente a dónde puede ir esa credencial.
Esa frase es la promesa completa. Veil es un servidor MCP más un intermediario seguro de entrada: el agente dice "pon la clave de producción de Stripe en Google Secret Manager", el humano ve exactamente qué proyecto y secreto se escribirán y escribe el valor en la ventana propia de Veil, y el valor va directamente al destino. El modelo nunca lo posee.
Implementado a partir de SPEC.md.
Veil es un servidor MCP stdio, por lo que no lo ejecutas tú mismo — tu cliente MCP lo inicia. El
patrón habitual de Python-MCP se aplica: uvx lo obtiene y lo ejecuta en un entorno
desechable, exactamente como npx -y lo hace para servidores TypeScript. Requiere uv
y Python 3.11+.
claude mcp add veil -e VEIL_ENV_ALLOWED_ROOTS="$PWD" -- \
uvx --from git+https://github.com/rosostolato/veil-mcp veil-mcp serveAñade -s project para registrarlo en el .mcp.json del repositorio en lugar de en tu propia configuración.
Inserta esto en el archivo de configuración MCP del cliente — el bloque mcpServers tiene la misma
forma en todas partes:
{
"mcpServers": {
"veil": {
"command": "uvx",
"args": [
"--from", "git+https://github.com/rosostolato/veil-mcp",
"veil-mcp", "serve"
],
"env": {
"VEIL_ENV_ALLOWED_ROOTS": "/absolute/path/to/your/project"
}
}
}
}Una vez que Veil esté en PyPI, el par --from git+… desaparece y la invocación se convierte en
uvx veil-mcp serve. Los destinos en la nube necesitan sus extras — veil-mcp[gcp],
veil-mcp[firestore], o ambos — añadidos a la especificación que uses.
Prefiere una instalación permanente a una efímera:
uv tool install "veil-mcp[gcp] @ git+https://github.com/rosostolato/veil-mcp"
# then use `veil-mcp serve` as the command, with no uvxEstablece VEIL_ENV_ALLOWED_ROOTS. El adaptador .env se niega a escribir fuera de esos
directorios, y por defecto solo permite el directorio de trabajo del servidor. Todo lo demás es
opcional — consulta Configuración.
Pídele a tu agente algo como "guarda mi clave de prueba de Stripe en .env". Lo que sucede:
El agente llama a secret.store describiendo dónde va la credencial. No envía ningún
valor, porque la herramienta no tiene un campo que pueda transportarlo.
Veil abre su propia ventana en tu máquina mostrando el nombre de la credencial, el destino, el proyecto, el entorno, la operación y el riesgo. El agente no recibe ese enlace.
Escribes el valor en un campo enmascarado. Las operaciones de riesgo medio y alto solicitan una segunda confirmación, después de la entrada y antes de la escritura.
Veil lo escribe y le dice al agente STORED más una referencia de destino — nunca el
valor.
El stderr propio de Veil lleva un registro de auditoría JSON estructurado. No se espera nada más de ti en la terminal.
Related MCP server: Janee
Elimina una clase completa de fallos causados por el agente conociendo el secreto. Con Veil en el bucle, una credencial no pasa a través de:
Prompts de LLM o historial de conversación
Argumentos de herramientas MCP o resultados de herramientas
Memoria del agente o código generado
Argumentos de comandos de shell o argv del proceso
Registros, trazas de depuración o telemetría
URLs
Salida de comandos visible para el modelo
Veil no hace que un agente de IA sea confiable, y no es "IA segura". No garantiza que el agente eligió el destino correcto, que te entendió, que está libre de inyección de prompts, que el destino en sí mismo es seguro, que tu máquina está libre de compromisos, o que una credencial no pueda ser mal utilizada posteriormente por software que la recibe legítimamente.
Hay dos problemas separados aquí:
Pregunta | Respuesta de Veil |
¿Debería el agente conocer el secreto? | No. |
¿Debería el agente decidir solo dónde va el secreto? | No sin autorización humana. |
Veil responde esas dos. No pretende responder el resto.
Trusted with the credential value:
The human at the keyboard
Veil's secure input UI (loopback only, in your control)
Veil's secure input broker (this process)
The selected destination adapter
The destination provider (e.g. Google Secret Manager)
NOT trusted with the credential value:
The LLM
The agent / MCP client
The conversation
The prompt and any repository content it read
Generated code
Logs, telemetry, crash reportsEste diagrama no afirma que los componentes confiables sean invulnerables. Dice dónde se permite que exista la credencial. Veil es software sensible a la seguridad: si el propio Veil es malicioso o está comprometido, el límite desaparece. Su código fuente, dependencias y versiones merecen el escrutinio que le darías a cualquier herramienta que maneje credenciales.
El flujo del secreto — la ruta del humano, que el modelo no puede observar:
Human ─▶ Veil secure UI (127.0.0.1) ─▶ Broker ─▶ Adapter ─▶ DestinationEl flujo del agente — todo lo que el modelo ve:
LLM ─▶ MCP client ─▶ Veil MCP server ─▶ non-sensitive result metadataEl esquema de la herramienta MCP no tiene ninguna propiedad capaz de transportar una credencial. Eso es estructural,
no una instrucción de prompt: no hay un campo value, secret_value, password, token,
content o raw_secret para abusar, los esquemas cerrados rechazan propiedades desconocidas, y
los argumentos se examinan en busca de valores con forma de credencial antes de ser analizados.
{
"destination": "gcp-secret-manager",
"name": "STRIPE_SECRET_KEY",
"target": { "project": "my-production-project", "secret": "STRIPE_SECRET_KEY" },
"write_mode": "new-version",
"environment": "production",
"description": "Stripe production API key"
}Veil responde con un request_id, una clasificación de riesgo y el destino normalizado —
y abre su propia ventana de autorización en tu máquina. El agente consulta secret.status.
El agente no obtiene el enlace de autorización. Ese enlace es una capacidad: cualquier cosa
que lo posea puede completar la mitad humana del flujo, y un agente con un shell o una herramienta
HTTP es precisamente el modelo de amenaza. Veil lo entrega a tu navegador y lo imprime en su propia
consola. Establece VEIL_DISCLOSE_AUTHORIZATION_URL=true si tu configuración necesita que el agente
reenvíe el enlace (por ejemplo, una sesión remota o sin cabeza) — y entiende que esto
permite que un agente comprometido autorice su propia solicitud.
Herramienta | Propósito |
| Crear una solicitud de credencial. Devuelve metadatos no sensibles y un id de solicitud. |
| Consultar una solicitud. Nunca devuelve material de credencial. |
| Cancelar una solicitud pendiente; cualquier valor ingresado se destruye. |
| Invalidar una autorización e iniciar una nueva. Nada se edita en el lugar. |
| Listar destinos y los campos de destino que espera cada uno. |
La Etapa A muestra el nombre de la credencial, el proveedor de destino, el proyecto/cuenta, el recurso, la operación y el riesgo antes de que se ingrese el valor. Las operaciones de alto riesgo (sobrescritura en producción, almacenamiento en texto plano, bases de datos de aplicaciones, reemplazo de una credencial) requieren una segunda confirmación en la Etapa B, después de la entrada y antes de la escritura. El valor nunca se muestra de vuelta.
La página que el humano lee y la operación que el ejecutor realiza son el mismo objeto inmutable — no hay un "destino de visualización" separado. Cualquier cambio en el destino, proyecto, nombre del secreto, operación, modo de escritura o adaptador invalida la autorización y requiere una nueva.
Adaptador | Clase | Notas |
|
| Preferido. Necesita |
|
| Restringido por ruta, rechaza enlaces simbólicos, escritura atómica |
|
| Necesita |
Los destinos arbitrary-network (HTTP POST genérico, webhooks) no están implementados, y
el registro de adaptadores se niega a registrar uno.
Dicho claramente, porque una herramienta de seguridad que se sobrevende es peor que ninguna:
El proceso intermediario ve el secreto. Ese es el punto: algo debe hacerlo, o el almacenamiento es imposible. La garantía es que solo los componentes mínimos de transporte y destino confiables lo hacen.
CPython no puede borrar memoria de forma confiable. SecretBuffer limpia el búfer mutable que posee,
pero la decodificación de porcentajes, las conversiones str/bytes y los SDK de proveedores crean copias inmutables
que el intérprete puede conservar hasta el recolector de basura. Veil minimiza y no fabrica esta garantía.
La UI es HTTP de bucle local. Cualquier proceso que se ejecute como tu usuario en tu máquina puede alcanzarla, y cualquier proceso de ese tipo también podría imitarla. Cada proceso de Veil imprime una frase de identidad aleatoria que sus páginas muestran (ayuda contra suplantación, no un control criptográfico). Ocultar el enlace al agente eleva el listón; no detiene un proceso que pueda leer la salida de la consola de Veil, listar el argv del navegador o escanear puertos de bucle local.
Veil no audita el destino. Si autorizas una credencial en un documento de Firestore, Veil la escribe allí y te dice que es una mala idea; no te detiene.
Los tiempos de espera son a nivel de proveedor. Veil no puede cancelar una llamada bloqueante del SDK desde fuera de ella, por lo que cada adaptador pasa un tiempo de espera explícito al proveedor. Un SDK de destino que ignora su propio tiempo de espera aún puede mantener una solicitud — y su secreto — abierta.
La verificación previa es de mejor esfuerzo. Un proveedor que no está disponible en la verificación previa se informa como no disponible en lugar de adivinarse.
Semántica de fallo. Un fallo entre la escritura del proveedor y la respuesta puede dejar una credencial escrita sin un registro local de éxito. Veil informa la solicitud como fallida; el destino es la fuente de la verdad.
git clone https://github.com/rosostolato/veil-mcp && cd veil-mcp
uv venv
uv pip install -e ".[dev,gcp,firestore]"
# drive it the way a client would
uv run veil servePara apuntar un cliente a tu copia de trabajo, usa /path/to/veil-mcp/.venv/bin/veil-mcp como el
comando en lugar de uvx.
La configuración se lee del propio entorno de Veil — nunca de los argumentos de la herramienta, por lo que un agente no puede relajar una política:
Variable | Valor por defecto | Significado |
|
| Caducidad de la solicitud. |
|
| Límite superior para una escritura de destino. |
|
| Requerir confirmación para operaciones de riesgo medio. |
|
| Dirección de enlace de la UI segura. |
|
| Abrir la ventana de autorización automáticamente. |
|
| Devolver el enlace de autorización al agente. |
| directorio actual | Raíces dentro de las cuales el adaptador |
|
| Permitir escribir en un archivo env bajo git. |
| todos | Lista de permitidos separada por comas. |
uv run pytest # everything
uv run pytest tests/security # the adversarial suite only
uv run ruff check .
uv run mypyEl conjunto de seguridad es un requisito del producto, no un lujo. Contiene detección de fugas de canario a través de cada canal observable, pruebas de agente malicioso, fixtures de inyección de prompts, pruebas TOCTOU y de repetición, estrés de concurrencia de 100 vías, condiciones de carrera, rutas de fallo, simulación de fallo de proveedor, comprobaciones de UI y fuzzing. Una versión está bloqueada si algún canario se filtra, alguna omisión de autorización tiene éxito, alguna mutación posterior a la aprobación tiene éxito, alguna solicitud completada es repetible, algún secreto cruza un límite de solicitud, algún error bruto del proveedor llega a MCP, o alguna operación de alto riesgo omite la confirmación.
Consulta docs/SECURITY_MODEL.md para el mapa de invariantes a pruebas.
Versión 0.1.0, construida según SPEC.md, que permanece en el repositorio como la descripción autorizada del comportamiento previsto. Cada módulo y prueba sustancial cita la sección que implementa, para que un revisor pueda verificar el código contra el requisito en lugar de contra un resumen del mismo.
El MVP está completo y la suite completa — incluida la adversarial — pasa. Lo que queda antes de que alguien deba confiar en él en producción: revisión independiente, pruebas de factor humano de la interfaz de confirmación (SPEC.md §35) y artefactos de lanzamiento firmados (§43).
La seguridad es el producto aquí, por lo que el estándar para los cambios es específico en lugar de burocrático:
Un cambio que afecte el manejo de credenciales, la autorización o la superficie de MCP necesita una prueba que intente romper el invariante que afecta, no solo una que demuestre que funciona.
Nunca debilitar una prueba de seguridad para que una suite pase. Si una prueba revela una falla arquitectónica, la arquitectura es lo que cambia.
Las nuevas dependencias de tiempo de ejecución en el núcleo se oponen por defecto. El broker es la base de computación confiable para el material de credenciales; los SDK de proveedores van detrás de un extra opcional.
Ejecute ruff check ., ruff format --check ., mypy y pytest antes de abrir una solicitud de extracción.
¿Encontró una vulnerabilidad? Por favor, repórtela de forma privada a través de los avisos de seguridad de GitHub en lugar de abrir un problema público.
Licencia Apache 2.0 © 2026 Eduardo Rosostolato.
Cancel a pending request. Any credential already entered is destroyed.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly discloses a critical side effect: 'Any credential already entered is destroyed.' This is valuable transparency for a destructive mutation. However, it doesn't mention other effects like whether cancellation is reversible or requires special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, highly concise, and front-loaded with the core action ('Cancel a pending request') followed by a key consequence. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description doesn't explain return values or error conditions. While it covers the key destructive behavior, it lacks guidance on when to use the reason parameter, potential side effects beyond credential destruction, and any prerequisites. For a security-related tool, more context would be helpful, but the essential purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the parameters at all. It doesn't mention that request_id is required or that reason is optional. The schema itself provides clear names, but the description adds no additional meaning, leaving the agent to infer that request_id identifies the request and reason is for audit context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel a pending request' which is a specific verb (cancel) and resource (request). It distinguishes from siblings like secret.store and secret.revise, as it focuses on cancellation and the destruction of already-entered credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for pending requests ('Cancel a pending request') but gives no explicit guidance on when to use it versus alternatives, nor exclusions. It lacks context like 'use secret.revise to modify instead' or 'do not use for completed requests'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the destinations this Veil instance can write to, with the target fields each one expects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, and the description does not contradict it. It adds context about the content (target fields) which is useful for the agent. Given the annotation already covers safety, the description provides adequate extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description fully explains what it does and includes the key detail about target fields, which is likely sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameterswing schema coverage is 100% (vacuously). Baseline for 0 params is 4, and the description clarifies that the output includes target fields per destination, which adds contextual meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the specific resource (destinations this Veil instance can write to), and adds the detail about target fields. It distinguishes itself from sibling tools like store, cancel, revise, which involve mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to discover available destinations and their required fields), but does not explicitly contrast with alternatives. Since it's a simple listing tool, the purpose clarity implicitly covers usage, though no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a pending request and create a new one. The original authorization is invalidated and the human must authorize the new operation from scratch; an authorized operation can never be edited in place.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Logical name of the credential, e.g. STRIPE_SECRET_KEY. This is a label, never the credential value. | |
| target | Yes | Where the credential goes. Fields depend on the destination; call secret.destinations for the exact contract. | |
| request_id | Yes | ||
| write_mode | No | create | |
| description | No | Short human-readable purpose, shown to the user. | |
| destination | Yes | Which destination adapter should receive the credential. | |
| environment | No | Environment you believe this destination belongs to. Advisory only: Veil classifies the destination itself and uses the stricter of the two. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses that the original authorization is invalidated, the human must reauthorize from scratch, and authorized operations cannot be edited in place. This covers the key side effects and workflow consequences of a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the core action, and the second provides the key behavioral consequence and an important invariant. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with nested objects and no output schema, the description explains the compound nature and authorization consequences sufficiently. It could additionally mention that all parameters must be resubmitted for the new request, but the schema and existing wording make the required inputs inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so most parameters have descriptions already. The tool description adds context around request_id by referring to 'pending request' and 'new operation from scratch,' but it does not explain parameter interactions or destination-specific requirements beyond what the schema provides. This is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a compound operation: 'Cancel a pending request and create a new one.' The title, 'Replace a credential request with a corrected one,' further specifies the resource and intent, distinguishing this from sibling tools like secret.cancel and secret.store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool: when a pending request must be corrected, and specifically notes that 'an authorized operation can never be edited in place.' It doesn't explicitly contrast with secret.cancel or secret.store, but the described workflow makes the intended use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the non-sensitive status of a credential request. Never returns credential material.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| wait_seconds | No | Optionally block until the request reaches a terminal state or this many seconds elapse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the readOnlyHint annotation by guaranteeing that no credential material is ever returned. This safety guarantee is a key trait not covered by annotations, though it does not disclose blocking behavior or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and add a critical safety note. There is no unnecessary detail or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and a read-only annotation, but the description omits key behavioral details such as the optional blocking behavior via wait_seconds and what the response actually contains (e.g., status list, error scenarios). Without an output schema, the description should describe the return value format more fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the parameters. request_id is self-explanatory from its name, but wait_seconds is already described in the schema. With only 50% schema description coverage, the description fails to compensate for the missing request_id semantics or clarify how to obtain such an ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the status of a credential request and explicitly mentions it never returns credential material. This distinguishes it from siblings like secret.cancel or secret.store, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking status but provides no explicit guidance on when to use it versus alternatives. There is no mention of 'use when you need to check status' or exclusions like 'do not use to cancel requests'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the human to provide a credential and have Veil write it to the destination described here. The credential value is never passed through this tool, never returned by it, and never becomes visible to the model: the user enters it in Veil's own trusted window. Share the returned authorization_url with the user, then poll secret.status.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Logical name of the credential, e.g. STRIPE_SECRET_KEY. This is a label, never the credential value. | |
| target | Yes | Where the credential goes. Fields depend on the destination; call secret.destinations for the exact contract. | |
| write_mode | No | create | |
| description | No | Short human-readable purpose, shown to the user. | |
| destination | Yes | Which destination adapter should receive the credential. | |
| environment | No | Environment you believe this destination belongs to. Advisory only: Veil classifies the destination itself and uses the stricter of the two. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses that the credential value never passes through the tool, is never returned, and never becomes visible to the model—a key behavioral trait. It also outlines the multi-step process involving an authorization_url and polling. Annotations already signal destructive and open-world behavior, and the description complements these without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes essential security and workflow context. Every sentence earns its place, and there is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested target, multiple destinations, write modes, environment), the description covers the critical workflow and security aspects, and points to secret.destinations for detailed contracts. It does not explain write_mode or environment semantics, but those are well-documented in the schema. Overall, it is reasonably complete for a tool of this intricacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not directly elaborate on any input parameters, but the schema provides extensive descriptions for 83% of fields. It directs users to secret.destinations for the target contract, which covers the remaining nuance. Since the schema already carries the semantic load, the description adds little beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: asking the human for a credential and having Veil write it to a specified destination. It distinguishes itself from siblings like secret.status and secret.cancel by focusing on the store action and includes critical security context (credential not visible to model) and subsequent steps (share authorization_url, poll status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance: ask the user, share the authorization_url, and poll secret.status. It implies this tool is for new credentials but does not explicitly contrast with secret.revise or specify when not to use it. The flow is described well, but alternative exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0secret.cancelsecret.destinationssecret.revisesecret.statussecret.storeScored across 5 tools
Each tool has a clearly distinct role: status checks a pending request, store initiates a credential request, cancel aborts it, revise replaces it, and destinations lists available targets. No overlap in purpose, making agent selection unambiguous.
All tool names follow a consistent 'secret.<action>' pattern with clear, concise verbs (status, store, cancel, revise) and one noun (destinations). The pattern is uniform and predictable, though 'destinations' is a noun rather than a verb, it still fits the domain prefix style.
With 5 tools, the server is tightly scoped to credential request management. This is within the ideal range and each tool earns its place; no redundancy or bloat.
The tool surface covers the entire lifecycle of a credential request: create (store), read (status), update/replace (revise), delete (cancel), and context (destinations). There are no evident gaps—even revision gracefully handles invalidation of prior authorizations.
Give AI agents identity, scoped access, trusted context, and verifiable actions through MCP.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Credential isolation for AI agents: placeholder secrets, policy checks, optional human approval.
