Loading ToolBench
MCP server for ZeroCreds — collect credentials from users without exposing them to the LLM
ZeroCreds MCP presents two well-defined tools with clear, actionable descriptions and properly structured input schemas. Both tools follow the verb_noun naming convention (zerocreds_create_session, zerocreds_check_status) and include comprehensive parameter documentation. However, output schemas are not explicitly documented in the source code, and there is no error handling guidance to help LLMs recover from failure states. The tool descriptions are exceptionally well-written (180+ chars each) and include usage patterns ('poll every 5 - 10 seconds'), which demonstrates LLM-optimization awareness. Parameter schemas are properly typed with enums and descriptions. The main gaps are: (1) no documented return type schemas for either tool, (2) no error recovery guidance in descriptions, and (3) no idempotency or confirmation patterns for the stateful create_session operation, which writes to a secret store.
Checks whether the user has submitted the ZeroCreds form. Returns "pending" (still waiting), "done" (credentials saved successfully — you can now proceed), or "expired" (link timed out — create a new session if needed). Poll every 5–10 seconds after showing the URL to the user.
Creates a ZeroCreds credential collection session. Returns a one-time URL for the user to enter their credentials — the values go directly to the secret store and NEVER appear in the LLM context. Use this whenever you need a password, API token, or any sensitive data from the user. After calling this, show the URL to the user, then poll zerocreds_check_status every 5–10 seconds until status is "done".
Output schemas not documented. Tool descriptions do not specify what SessionResult or StatusResult fields the client should expect, forcing LLMs to infer structure from examples or make assumptions.
No error handling guidance. Tool descriptions do not explain how to recover from API failures (e.g., 'if destination is invalid, check ZEROCREDS_DEFAULT_DESTINATION env var'), authentication errors, or network timeouts. LLMs will not know what to do on failure.
No confirmation step for destructive/sensitive operations. zerocreds_create_session writes credentials to a secret store but has no dry-run or confirmation mechanism. An LLM could accidentally collect and store incorrect credentials without user review.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Destination parameter is overloaded and underdocumented. The 'destination' parameter accepts both string aliases ('os-keychain') and inline config objects ({"type":"os_keychain",...}), but the description does not explain which backends are supported, validation rules, or what happens if it's missing (relies on env var with no fallback error message).
Missing per-parameter validation constraints in descriptions. The 'ttl_minutes' parameter states 'max: 1440' but does not specify minimum (presumably 1 or 5); 'fields' array does not state min/max item count; field 'name' must match 'alphanumeric + _' but no regex or length bounds are documented.