Loading ToolBench
MCP server for LobsterVault — encrypted secret storage for agents
LobsterVault MCP demonstrates solid tool definitions with clear naming conventions, comprehensive parameter schemas, and thoughtful error handling. All 7 tools follow verb_noun patterns (set_secret, get_secret, delete_secret, list_secrets, inject_secrets, rotate_secret, get_account). Parameter descriptions are consistently present and specific. However, output schemas lack explicit documentation, and there are gaps in composition guidance and error recovery patterns. The server includes proactive tier-based error guidance (TIER_GUIDANCE map), which is excellent, but missing idempotent markers and confirmation patterns for destructive operations.
Permanently delete a secret.
Get your account tier, secret usage, and limits.
Retrieve and decrypt a secret value by name. Returns null if not found. Pass a version number to retrieve a specific historical version (Builder+ tier).
Load all secrets into the process environment (process.env). Returns the count of secrets injected. Use at agent startup to make all stored secrets available as env vars.
List all secret names on the account. Values are never returned in list operations.
Re-encrypt a secret with a fresh Data Encryption Key. Use after KMS key rotation or as a security best practice. Requires Pro tier.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns the new version number' for set_secret, 'Returns null if not found' for get_secret) but the structured response format is not formally specified. LLMs cannot reliably extract or chain these responses without explicit field names and types.
delete_secret lacks confirmation or dry-run capability. Destructive operations should support a confirmation_required pattern or dry-run option to prevent accidental deletion. Currently, a single call permanently deletes a secret with no recovery path.
No idempotent markers in tool definitions. The MCP spec (2026-07-28) supports toolAnnotations with idempotentHint and destructiveHint. These are absent from all tool registrations, limiting the LLM's ability to understand retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 65 | - | v1 |
Store or update a secret. The value is envelope-encrypted server-side using AWS KMS. Returns the new version number.
inject_secrets description lacks clarity on side effects. It modifies process.env globally, which is a WRITE operation with significant implications for agent state, but the description ('Load all secrets into the process environment') is terse and does not emphasize this is a one-time initialization step, not a query.
get_account description does not specify what fields are returned or what format (e.g., usage object, tier string, limits array). LLMs cannot plan downstream actions without knowing the response structure.
list_secrets pagination is documented in parameters (cursor, limit) but no guidance on total count or next_cursor return. Without knowing whether a full response was returned, agents may miss secrets or enter infinite pagination loops.