Free for now while in alpha pre-release-candidate phase

MCP Server

Give AI assistants direct access to your secrets vault. Sirr's MCP server lets tools like Claude store, read, and share ephemeral secrets without leaving the conversation.

What is MCP

The Model Context Protocol (MCP) is an open standard that allows AI assistants to interact with external tools and data sources. Instead of copy-pasting secrets between your terminal and an AI chat, MCP lets the assistant call Sirr directly.

Sirr's MCP server exposes a suite of tools that map to the core Sirr operations. When an AI assistant reads a secret through MCP, the same rules apply — read counters increment, TTLs are enforced, and one-time secrets burn after a single read.

MCP does not bypass any security constraints. Every tool call goes through the same authenticated HTTP API with the same TTL and read-limit enforcement.

Installation

One-liner for Claude Code:

Claude Code

claude mcp add --transport stdio sirr -- npx -y @sirrlock/mcp

Or install globally via npm:

Global install

npm install -g @sirrlock/mcp

After installation, the sirr-mcp binary is available on your PATH. Both methods work with Claude Code, Cursor, Windsurf, and any MCP client.

Configuration

Add Sirr to your MCP configuration file. Most AI tools look for .mcp.json in your project root or home directory.

Sirr Cloud (recommended)

If you use Sirr Cloud, no SIRR_SERVER is needed — the MCP server defaults to https://sirr.sirrlock.com. Use your principal key as the token.

Claude Code — Sirr Cloud

claude mcp add --transport stdio --env SIRR_TOKEN=your-principal-key --env SIRR_ORG=your-org-id sirr -- npx -y @sirrlock/mcp

.mcp.json — Sirr Cloud

{
  "mcpServers": {
    "sirr": {
      "command": "npx",
      "args": ["-y", "@sirrlock/mcp"],
      "env": {
        "SIRR_TOKEN": "your-principal-key",
        "SIRR_ORG": "your-org-id"
      }
    }
  }
}

Self-Hosted

If you run your own sirrd instance, set SIRR_SERVER to your server's address and use the master API key as the token.

Claude Code — Self-Hosted

claude mcp add --transport stdio --env SIRR_SERVER=http://localhost:39999 --env SIRR_TOKEN=your-master-api-key sirr -- npx -y @sirrlock/mcp

.mcp.json — Self-Hosted

{
  "mcpServers": {
    "sirr": {
      "command": "npx",
      "args": ["-y", "@sirrlock/mcp"],
      "env": {
        "SIRR_SERVER": "http://localhost:39999",
        "SIRR_TOKEN": "your-master-api-key"
      }
    }
  }
}

Environment variables

  • Name
    SIRR_SERVER
    Type
    string
    Description

    URL of the Sirr server. Defaults to https://sirr.sirrlock.com (Sirr Cloud). Set to http://localhost:39999 for local self-hosted instances.

  • Name
    SIRR_TOKEN
    Type
    string
    Description

    Bearer token for authentication. For Cloud users, this is your principal key from sirrlock.com. For self-hosted, this is the value of SIRR_MASTER_API_KEY on the server.

  • Name
    SIRR_ORG
    Type
    string
    Description

    Organization ID for org-scoped secrets. When set, store_secret and read_secret with a name route through this org. Required for Cloud; optional for self-hosted.

CLI flags

  • Name
    --version
    Description

    Print the installed sirr-mcp version and exit.

  • Name
    --health
    Description

    Check that the MCP server can reach Sirr and exit with code 0 on success or 1 on failure. Safe to use in scripts and CI.

Verify — Cloud

SIRR_TOKEN=your-principal-key \
SIRR_ORG=your-org-id \
sirr-mcp --health

Verify — Self-Hosted

SIRR_SERVER=http://localhost:39999 \
SIRR_TOKEN=your-master-api-key \
sirr-mcp --health

Print installed version

sirr-mcp --version
# sirr-mcp 0.1.0

Available tools

The MCP server exposes five tools — just enough to store, read, check, share, and audit secrets.

store_secret

Store a secret in Sirr. Without a name, creates an anonymous burn-after-read dead drop (returns a one-time URL). With a name (requires SIRR_ORG config), stores a named secret in your org vault.

  • Name
    value
    Type
    string
    Description

    The secret value.

  • Name
    name
    Type
    string
    Description

    Key name for org-scoped storage. Omit for anonymous dead drop. Requires SIRR_ORG.

  • Name
    ttl_seconds
    Type
    number
    Description

    Time-to-live in seconds. Optional.

  • Name
    max_reads
    Type
    number
    Description

    Max reads before the secret burns. Default: 1 for anonymous dead drops. Optional.

read_secret

Read a secret from Sirr. By ID: retrieves a public dead-drop secret. By name: retrieves from your org vault (requires SIRR_ORG). The read counter increments — the secret may burn after this call.

  • Name
    id
    Type
    string
    Description

    Public secret ID (from store_secret). Use for anonymous dead drops.

  • Name
    name
    Type
    string
    Description

    Secret key name for org-scoped retrieval. Accepts sirr:KEYNAME or bare name.

check_secret

Check if a secret exists and inspect its metadata — without consuming a read. Returns status (active/sealed), reads used/remaining, and expiry. Safe to call repeatedly.

  • Name
    name
    Type
    string
    Description

    Secret key name. Accepts sirr:KEYNAME or bare name.

share_secret

Create a burn-after-read link for sharing a secret with someone outside your org. No account needed on either end. Burns after 1 read or 24 hours.

  • Name
    value
    Type
    string
    Description

    The sensitive value to share.

audit

Query the Sirr audit log. Shows recent events: secret creates, reads, deletes. Useful for verifying a secret was burned or investigating access patterns.

  • Name
    since
    Type
    number
    Description

    Only return events after this Unix timestamp. Optional.

  • Name
    action
    Type
    string
    Description

    Filter by action type, e.g. secret.create, secret.read. Optional.

  • Name
    limit
    Type
    number
    Description

    Maximum events to return. Defaults to 50. Optional.

Everything else — webhooks, API keys, orgs, roles, principals — is managed via the CLI or web dashboard. The MCP server is intentionally lean: store, read, share, check, audit.

Conversation examples

Here is what it looks like when Claude uses Sirr through MCP.

Burn after read — across sessions

Session 1 — store the secret

❯ store the BITBUCKET_TOKEN 123asdzxc

⏺ sirr-mcp - store_secret (MCP)(name: "BITBUCKET_TOKEN", value: "123asdzxc", max_reads: 1)
  ⎿  Stored secret 'BITBUCKET_TOKEN'. Burns after 1 read.

⏺ Stored. Burns after first read.

Session 2 — Claude retrieves and uses it (vault burns it)

❯ deploy to staging using the BITBUCKET_TOKEN

⏺ sirr-mcp - read_secret (MCP)(name: "BITBUCKET_TOKEN")
  ⎿  123asdzxc

⏺ Got it. Deploying to staging with the token. Done.

Session 3 — secret is already gone

❯ what is the BITBUCKET_TOKEN?

⏺ sirr-mcp - read_secret (MCP)(name: "BITBUCKET_TOKEN")
  ⎿  Secret 'BITBUCKET_TOKEN' not found, expired, or already burned.

⏺ The secret no longer exists on the server.

The secret was burned the moment it was first read — by the vault (max_reads=1), not by convention. The read_secret tool description also instructs Claude not to memorize or repeat secret values. Two independent layers: server-side destruction and agent-level instruction.

Storing with a TTL

Conversation

User:  Store this API key in Sirr with a 2-hour TTL: sk-live-abc123

AI:    [Calls store_secret(value: "sk-live-abc123", ttl_seconds: 7200)]

       Done. Secret stored with ID a3f8...7c2d. URL: https://sirr.sirrlock.com/s/a3f8...7c2d
       It will self-destruct in 2 hours.

Claude never caches secret values between sessions. Each retrieval is a live call to the Sirr server with full TTL and read-limit enforcement.

Troubleshooting

Token mismatch (401)

Your SIRR_TOKEN must be a valid credential. For Cloud users, this is a principal key from sirrlock.com. For self-hosted users, this must match the SIRR_MASTER_API_KEY on the server exactly. A single extra character or newline will cause every authenticated tool call to fail.

Diagnose: sirr-mcp --health will show a 401 error if the token is wrong. See sirr.dev/errors#401.

Free-tier limit (402)

If store_secret fails with a 402 error, your instance has reached 100 active secrets. Delete or let expire the secrets you no longer need, or set SIRR_LICENSE_KEY to unlock unlimited usage. See sirr.dev/errors#402.

Permission denied (403)

A scoped API key was used but lacks the permission for the operation — for example, a read-only key trying to push or delete. Re-create the key with the needed permissions. See sirr.dev/errors#403.

Server unreachable

If tool calls time out after 10 seconds:

  1. Run sirr-mcp --health to confirm connectivity outside of an AI session
  2. Check that SIRR_SERVER in .mcp.json matches the address Sirr is listening on
  3. If Sirr is on a remote host, verify network access and that the server is running

SIRR_TOKEN missing

On startup, if SIRR_TOKEN is absent, sirr-mcp logs a warning to stderr. Anonymous dead drops and share links still work, but org-scoped secrets require a token. Add SIRR_TOKEN to the env block in .mcp.json. See sirr.dev/errors#401.

Plain HTTP on a remote host

If SIRR_SERVER is a non-local http:// URL, sirr-mcp warns that secrets will be transmitted unencrypted. Switch to https:// or secure the connection at the network level.

Was this page helpful?