Loading ToolBench
Zero-exposure credential vault and identity layer for AI agents, over MCP. Your agent uses your API keys without ever seeing them - and every run is attributable, budgeted and auditable.
keywarden demonstrates strong naming conventions (verb-first: list_, describe_, http_, run, audit_) and comprehensive parameter descriptions. All 6 tools have detailed, action-oriented descriptions (avg ~150 chars). Input schemas are fully specified with types and constraints. However, output schemas are not documented in the visible code, the tool definitions show only inputSchema, not what each tool returns. Error handling is mentioned in descriptions (e.g., 'Output is scanned and any credential appearing in it is masked') but recovery guidance is minimal. Security-focused design (no get_secret tool, credential masking, audit logging) is excellent. Parameter naming is precise (ref, method, url, timeout_ms) with clear type suffixes.
Recent entries from keywarden's tamper-evident audit log: which credential was used, by which capability, against which host or command, and whether it was allowed or denied.
Metadata for one credential plus how it can be used: whether it can be proxied over HTTP, which hosts it may reach, and which environment variables it maps to when injected.
Make an authenticated HTTPS request using a vaulted credential. keywarden attaches the credential itself; you never see it. The destination must be an allowed host for that credential. Redirects are not followed and non-HTTPS is refused.
List known provider presets (openai, aws, stripe, ...) with their allowed hosts, expected field names, and env-var mappings. Useful before asking the user to add a new credential.
List every credential in the vault as metadata only: ref, provider, description, which field names exist, when it was last used. Never returns credential values. Start here.
Output schemas not documented. Tool definitions show inputSchema but no documented return types or field structures. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns.
Error handling lacks recovery guidance. Descriptions mention constraints (e.g., 'Redirects are not followed') but do not explain what the LLM should do if a call fails. No guidance on retryability, user-fixable vs. fatal errors, or alternative approaches.
http_request and run tools are high-risk (WRITE, IRREVERSIBLE) but lack confirmation/dry-run patterns. No mention of preview mode, confirmation step, or rollback capability for destructive operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Run a local command with one or more vaulted credentials injected as environment variables (e.g. aws, terraform, gh, psql, a build script). The command is executed directly with no shell, so pass arguments as an array. Output is scanned and any credential appearing in it is masked before you see it.
Parameter constraints not fully formalized. timeout_ms and limit parameters lack explicit min/max bounds in schema (e.g., audit_tail limit defaults to 20, max 200, but schema shows only type:number with no constraints).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked READ_ONLY or WRITE/IRREVERSIBLE in metadata but not via MCP tool annotations, limiting client-side safety checks.