An MCP server and secure input broker: an AI agent can place a credential without ever receiving it, while a trusted human-controlled UI authorizes where it goes.
Veil MCP demonstrates strong security-first design with well-structured tool definitions. All 5 tools have complete input schemas with proper JSON Schema validation (additionalProperties: false, required fields, type constraints). Descriptions are detailed and security-focused, explaining what tools do NOT do (e.g., 'never the credential value'). Tool names follow verb_noun pattern (secret_store, secret_status, secret_cancel, secret_revise, secret_destinations). Parameters are well-described with constraints (maxLength, min/max for integers). However, output schemas are not explicitly documented in the visible code, only input schemas are shown. Error handling is present but recovery guidance could be more explicit in descriptions. Tool annotations are properly implemented with readOnlyHint, destructiveHint, idempotentHint, openWorldHint flags.
Cancels a pending credential request and destroys any value the user already entered. Returns the final state. Cannot cancel a request that is already writing to its destination, and cannot undo a completed write.
Lists the destinations this Veil instance can write to, with the target fields and write modes each one accepts. Reads only; creates no request.
Cancels a pending request and creates a replacement with different details. The original authorization is invalidated and the user authorizes the new operation from scratch; an authorized operation is never edited in place. Returns the new request id. Use secret_cancel when no replacement is wanted.
Returns the current state of one credential request: its stage, destination, risk, and the outcome once it is finished. Never returns credential material. Reads only — use secret_store to create a request.
Creates a request to store a credential at the described destination and opens Veil's own authorization window on the user's machine, where the user reviews the destination and types the value. Returns a request id, the normalized destination, a risk classification and the request state — never the credential value, which no Veil tool accepts or returns. Does not write anything by itself: the write happens only after the user authorizes it. Use secret_status to follow the request, and secret_revise to change an already-authorized destination.
Output schemas not documented in visible code. Tool descriptions explain what is returned (request_id, normalized destination, risk classification, request state) but formal output schema definitions are absent from src/mcp/tools.ts. LLMs cannot plan downstream operations without knowing response structure.
secret_revise has no required fields in input schema. All parameters are optional, yet the tool description implies at least request_id is needed to identify which request to revise. This creates ambiguity: can the tool be called with zero arguments?
Error handling descriptions are minimal. Tools mention what they cannot do (e.g., 'Cannot cancel a request that is already writing') but do not provide recovery guidance. If cancellation fails, what should the agent do next?
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2025-06-18+ | v2 |
secret_destinations accepts empty input object but its purpose (list available destinations) is not explicitly stated in the description. The description says 'Lists the destinations' but does not explain when to call it or what structure each destination object contains.
Tool composition assumes agent knows the workflow: call secret_destinations first to discover adapters, then secret_store with a destination. This multi-step dependency is not documented in tool descriptions. Agents may call secret_store without knowing valid destinations.