Loading ToolBench
Privacy-first AI personal data manager. Local MCP server that external AIs command via the Model Context Protocol. Provides encrypted vault operations for secrets and knowledge, denying external AIs access to raw document content.
The Enclave Vault MCP server has 7 tools with basic schema definitions and descriptions. However, critical gaps limit production readiness: (1) Many parameter descriptions lack detail on valid values, ranges, and formats expected by LLMs. (2) Output schemas are not documented, responses are inferred rather than explicitly specified. (3) Error handling lacks actionable recovery guidance. (4) Two LangChain integration tools mention external API key configuration but do not specify how credentials are injected securely. (5) The vault_delete tool uses only 'service' as an identifier, which is overly coarse for a destructive operation, no ID-based deletion or confirmation step. Tool naming is clear and action-verb based, descriptions are present but terse (averaging ~80 chars), and schemas have types but lack comprehensive validation guidance. This server lands in the C-to-D range: fair definitions with noticeable gaps.
Retrieve a secret from Enclave vault with policy enforcement (LangChain integration). Requires API key configuration. Returns encrypted secret that needs client-side decryption.
Query a knowledge adapter via DoRA inference (LangChain integration). Requires API key configuration. Returns DoRA-synthesized response.
Delete an entry from the vault by ID or service name.
List all entries in the vault, optionally filtered by tag or service.
Query the vault using natural language. Automatically routes to exact data (Layer 1) or knowledge (Layer 2) based on query type. Examples: 'What's my Stripe API key?' (exact), 'Why did I choose Stripe?' (knowledge), 'Show me everything about Stripe' (hybrid).
Get vault statistics (total entries, services, layer status).
Output schemas are completely undocumented. None of the 7 tools specify the structure, field types, or format of their responses. LLMs cannot compose tools or extract required fields for chaining.
vault_delete tool description claims deletion 'by ID or service name' but the schema only accepts 'service'. This mismatch causes specification confusion. No confirmation step or dry-run for a destructive operation.
LangChain integration tools (langchain_get_secret, langchain_query_knowledge) mention 'Requires API key configuration' and encryption/decryption but provide no details on WHERE keys are stored, HOW they are injected, or the ENCRYPTION PROTOCOL. Security-critical information is missing.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 26 | - | v1 |
Store a secret or knowledge in the vault. Use 'secret' type for API keys, passwords, tokens. Use 'knowledge' type for setup notes, documentation, context.
Parameter descriptions lack actionable constraints. Examples: (1) 'service' parameter accepted by 4 tools, no guidance on valid formats, uniqueness, or case sensitivity. (2) 'tag' arrays with no max length or naming rules. (3) 'query' strings with no length limits or structure hints. LLMs cannot validate input without explicit constraints.
No error handling guidance. What happens if vault_recall finds no matches? If vault_delete targets a non-existent service? If langchain_get_secret fails due to policy denial? No recovery instructions for LLMs.
vault_list_entries and vault_stats lack pagination guidance. No mention of result limits, total counts, or cursors. Large vaults could return thousands of entries, exhausting context.
vault_recall description mentions 'Layer 1' and 'Layer 2' routing but never defines what layers are, how they differ, or what the agent should expect. The abstraction is opaque.
LangChain tool names couple to implementation details. 'langchain_get_secret' and 'langchain_query_knowledge' should be 'get_secret' and 'query_knowledge'. Users don't know or care about LangChain.
No documented return field names or types for any tool. If vault_store succeeds, does it return entry_id, id, uuid, or nothing? If vault_list_entries returns entries, do they have id, name, type, created_at, service, tags fields? Composition chains are broken.