Loading ToolBench
An MCP server for managing encrypted local secrets vault. Allows reading and writing secrets from projects and environments, with support for approval-tier access control and daemon-backed Touch ID authentication.
Lokalite MCP Server demonstrates solid definition quality with well-named tools, comprehensive descriptions, and complete input schemas. All 8 tools follow verb_noun naming conventions (get_secret, list_projects, add_secret, etc.). Descriptions are action-oriented and explain WHAT, WHEN, and consequences. Input schemas are complete with type definitions and parameter descriptions. However, there are notable gaps: output schemas are not formally documented, error handling guidance is present but minimal, and no tool annotations (readOnlyHint/destructiveHint) despite clear semantic categories (READ_ONLY vs WRITE vs DESTRUCTIVE marked in metadata). The server correctly enforces access control policies (agent blockers, approval requirements) and handles secret values securely (never returning them directly), which is exemplary. Descriptions average ~120 chars, within the 10-1024 char optimal range. All required parameters are marked and described. The main limitation is lack of structured output documentation and tool annotations that would help LLMs reason about side effects.
Creates a new secret in a project environment. Requires write mode to be enabled (--read-write flag).
Deletes a secret from a project environment. Requires write mode to be enabled (--read-write flag). Respects governance policies that may prevent deletion.
Retrieves a secret value and returns a one-time source command that loads it into the shell environment. The value is never shown in the response — it is written to a temporary script file that self-deletes after sourcing. Does not return the value directly.
Lists all environments in a project, indicating which is currently active. Returns no secret values.
Lists all projects in the vault with their names, linked directories, and active environments. Returns no secret values.
Lists all secrets in an environment with their names, descriptions, categories, and access control annotations (off-limits to agents, approval required, etc.). Returns no secret values.
Output schemas not formally documented. Tools return content/error objects but structure is inferred from code, not declared in tool definitions. Agents cannot predict downstream field names or types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic categories in code (READ_ONLY, WRITE, DESTRUCTIVE). LLMs cannot reason about side effects or retry safety without explicit markers.
Destructive operations (delete_secret) lack confirmation or dry-run pattern. Agents could permanently delete secrets without explicit user approval. No recovery mechanism offered.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Updates an existing secret's value. Requires write mode to be enabled (--read-write flag). Respects governance policies that may prevent updates.
Sets the active environment for a project. The active environment is shared across the app, CLI, and agents.
Error messages in code are clear ('Secret not found...'), but tool descriptions do not document what errors are returned or how agents should recover. E.g., set_secret says 'respects governance policies' but doesn't explain what error agents see if a policy blocks the update.
Parameter 'environment' in list_environments input schema is unclear, is it required to filter listings, or optional? Description doesn't explain the relationship between the required 'project' context and optional 'environment' parameter.
No idempotency guarantees stated for write tools (add_secret, set_secret, delete_secret). Agents cannot safely retry on ambiguous failures without risk of duplicates or unintended side effects.