Loading ToolBench
Local encrypted vault MCP server with Argon2id, AES-256-GCM, authenticated REST, bounded MCP transport, and opt-in raw resolution.
The server defines 2 tools with clear, focused purposes aligned with secret management. Both tools have explicit schemas with parameter validation and descriptions. However, descriptions lack context about when to use each tool, what fields are returned, and recovery guidance. Parameter descriptions exist but are sparse. No output schemas are documented. Error handling categorizes errors (publicCodes) but doesn't guide LLM recovery. Tool naming follows verb_noun convention (enigmagent_list, enigmagent_resolve) but uses a domain-specific prefix that may confuse generic LLM selection.
List secret names and bound domains. Values are never returned.
Returns a plaintext secret to this client. Disabled by default; enable only for a trusted client. The origin is caller-declared, not attestation.
Tool descriptions lack context on what data is returned and when to use each tool. 'List secret names and bound domains' doesn't explain the response structure (is it an array? object? what fields?). 'Returns a plaintext secret' doesn't explain dependencies (must call list first?) or use cases.
No output schemas documented. The code shows vault.list() and vault.resolve() are called, but the actual return structure is not specified in tool definitions. LLMs cannot plan downstream calls without knowing the response format.
enigmagent_resolve parameter 'origin' description is sparse. States it is 'HTTP or HTTPS origin URL for domain binding verification' but doesn't explain: why is origin required? What does 'domain binding' mean? What happens if origin doesn't match the secret's bound domain? LLM has no recovery guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
Error handling returns only the error code (e.g. 'no_domain_binding', 'raw_resolve_disabled') via toolResult(publicError(error), true). No actionable guidance. When an LLM gets 'no_domain_binding', it doesn't know what to do next: should it retry? call enigmagent_list first? ask the user? A raw error code is not recovery guidance.
placeholder parameter in enigmagent_resolve has regex constraint in schema (/^[A-Za-z0-9_:.@-]{1,128}$/) but the description does not mention this constraint. LLM cannot read JSON Schema patterns from descriptions, it relies on the description text to understand format rules.
Tool names are prefixed with 'enigmagent_' which is domain-specific and may not clearly signal intent to a generic LLM. 'list' and 'resolve' are action verbs, but the prefix obscures them. For an LLM with 50+ tools, 'enigmagent_list' competes poorly against 'list_secrets' or 'get_secret_value'.
No dependency documentation. If enigmagent_resolve fails with domain_mismatch, should the user call enigmagent_list first to see available secrets? Or re-check the origin parameter? The tool descriptions don't hint at multi-step workflows.