MCP server for managing SikkerKey vault operations including AI agents, machines, projects, secrets, policies, enrollment tokens, canaries, alerts, audit logs, IP allowlists, and SDK documentation.
SikkerKey MCP demonstrates solid tool design with consistent naming patterns (manage_* prefix), comprehensive parameter schemas with enums and descriptions, and clear security-focused documentation. All 11 tools have descriptions (avg ~180 chars) and input schemas with typed parameters. However, output schemas are not documented, error handling lacks recovery guidance, and some parameter descriptions could be more prescriptive about constraints and formats. The server shows good security awareness (scope declarations, permission gating) but misses LLM-optimized error messages and confirmation patterns for destructive operations.
Manage AI agent identities on the vault — list, inspect, approve / deny pending agents, enable / disable, rename, view rename history, and revoke. Bootstrap-token issuance, scope-set mutation, and project-allowlist mutation are NOT exposed here (privilege-escalation paths) and remain dashboard-only.
Manage which audit actions trigger alerts (email + webhook dispatch). The vault owner picks which actions are noisy enough to wake them up.
Manage canary secrets — defensive trip-wires that freeze the project (and optionally related projects) when read by an unexpected machine. Also handles project unfreeze recovery.
Manage enrollment tokens — multi-use credentials that ephemeral machines (CI runners, autoscaling pods) use to bootstrap themselves into specific projects + secret grants.
Manage the IP allowlist that gates machine authentication for the vault. Note: only applies to MACHINE Ed25519 auth and enrollment — dashboard JWT sessions are intentionally not gated by this. Disabling drops the gate entirely; configure carefully.
Output schemas not documented. Tools return JSON via pretty() but LLMs cannot predict response structure for downstream chaining. Missing field documentation for pagination, error objects, and nested resources.
Error handling lacks recovery guidance. Errors are returned as raw API responses without actionable next steps. E.g., 'agent not found' should suggest 'Try manage_ai_agents list action' or 'Check agent ID format'.
Destructive operations (revoke, deny, delete) lack confirmation/dry-run patterns. manage_machines.revoke and manage_projects.delete have preview flags but others do not. Agents can accidentally cascade-delete resources without confirmation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Manage signed machine identities for the vault. Used to list machines, approve pending ones, rename, revoke, and view rename history. Note: machines are secret CONSUMERS — for the AI agent's own management surface use the project-machines tool instead.
Manage access policies and their bindings to secrets. A policy is a layered set of constraints (time window, IP allowlist, rate cap, co-sign, TTL, rotate-after-N) that applies on top of the base six-requirement gate.
Manage which machines are attached to a project and which secrets they can read. The vault's six-requirement gate: a machine reads a secret only if it's approved, in the project, and explicitly granted that secret. This tool is how those grants get set.
Manage projects (the unit of secret isolation in the vault). When the agent has a project allowlist, create auto-adds the new project to that allowlist so the agent can act on what it just made.
Look up SikkerKey's official runtime SDKs — install commands, runtime requirements, docs links, and quick-start code snippets. Use this when the customer asks how to read a secret from their application (Python, Node.js, Go, .NET, or Kotlin/JVM) so you can hand them working code instead of a doc link. No scope required — vendor reference data.
Read the vault's audit log, activity feed, and usage stats. Useful for investigating who did what when, exporting compliance evidence, and surfacing usage trends.
Parameter descriptions lack prescriptive constraints. E.g., 'name' params say '1-255 chars' in description but should also specify allowed characters (alphanumeric, hyphens, underscores?). Format constraints should be explicit, not inferred.
Pagination not consistently exposed. read_audit supports page/pageSize but manage_ai_agents.list does not. Large result sets (100+ agents) will bloat context. All list/query actions should support limit and cursor/offset.