Local MCP server for secret handoff through the OS keyring without exposing plaintext to model context
Four tools with clear action verbs and reasonable descriptions (90-150 chars each). Input schemas present with type definitions and parameter descriptions. However, output schemas are not documented in the visible code, parameter descriptions lack format/constraint details (e.g., ttl_seconds accepts 'string' but should validate integer range 1-86400), and error handling guidance is absent. Tool names follow verb_noun pattern well (secret_handoff_*), but descriptions could be more specific about when to use each tool vs. alternatives. No evidence of pagination, structured output documentation, or recovery guidance in error cases.
Capture a secret through a trusted GUI prompt or TTY input, storing it in the OS keyring with automatic expiration
Retrieve a previously captured secret from the OS keyring by its handle
Revoke and immediately delete a secret from the OS keyring
List all active secrets and their current status, including expiration times and lifecycle information
Output schemas not documented. No visible schema definitions for tool responses (e.g., what fields does secret_handoff_capture return? Is it a handle string, or an object with handle + metadata?). LLMs cannot plan downstream calls without knowing response structure.
Parameter ttl_seconds has type 'string' but description says 'must be a valid integer between 1 and 86400'. Type should be 'integer' with minimum/maximum constraints in schema, not string. This invites LLM confusion and validation errors.
No error handling guidance. Tool descriptions do not explain what happens on failure (e.g., 'If secret not found, returns error X. Try secret_handoff_status() to list available secrets.'). Agents have no recovery path on errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2025-06-18+ | v2 |
secret_handoff_status has empty input schema ({}). Description does not explain what it returns (list of secrets? summary? per-secret details?). Without output schema, LLM cannot extract handle IDs for downstream retrieve/revoke calls.
Destructive tool (secret_handoff_revoke) lacks confirmation/dry-run pattern. No mention of whether the operation is idempotent or what happens if called twice with same handle. Agents need to know if retry is safe.