MCP server for ZeroCreds — collect credentials from users without exposing them to the LLM
The ZeroCreds MCP server defines 2 tools with clear, well-structured schemas and descriptions. Both tools have comprehensive input schemas with proper type definitions and field descriptions. Tool descriptions are substantive (150-200 chars) and explain WHEN to use the tool and WHAT to expect. However, there are significant gaps in error handling guidance, output schema documentation, and parameter validation constraints. The tools lack descriptions for return values, making it harder for LLMs to understand what they'll receive. Parameter constraints are documented in descriptions but not enforced via formal JSON Schema constraints (e.g., ttl_minutes lacks min/max bounds despite mentioning 'max: 1440'). No error recovery guidance is provided, if a session expires or the API fails, the LLM gets no instruction on how to recover. The server uses proper verb_noun naming (create_session, check_status) which is good, but output documentation is missing entirely.
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. Neither tool documents what fields are in the response (e.g., zerocreds_create_session should document that it returns {token: string, url: string, expires_at: string}). LLMs cannot plan downstream calls without knowing the response structure.
No error handling or recovery guidance in tool descriptions. If zerocreds_create_session returns an error (e.g., 'unauthorized', 'network timeout'), the description does not tell the LLM what to do next. For check_status, there is no guidance on how long to wait before the link expires or how to handle 'expired' status gracefully.
Parameter constraints lack formal JSON Schema enforcement. ttl_minutes mentions 'max: 1440' in the description but no JSON Schema maximum constraint is present. The 'fields' parameter requires each field object to have 'name' and 'label', but the items schema does not specify additionalProperties or enforce strict validation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Missing parameter descriptions for critical inputs. The 'destination' parameter has a long description, but the 'fields' array itself lacks guidance on what happens if fields are empty or if duplicate field names are provided. The type constraint for Field.type is documented in the description but the inline enum in the schema could be clearer.