Which integrations are available for this server?

Enables commit-safe .env files by replacing secret values with placeholder references (secret://NAME) and expanding them to real values at runtime via CLI.

How do I use claude-secrets?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claude-secrets Retrieve my GitHub token" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

claude-secrets

by vaultry

Overview Schema Related Servers Score Discussions

JavaScript

Local

Claude Secrets

@vaultry/claude-secrets

Encrypted token store for Claude Code sessions and your shell/apps. macOS Keychain backed · MCP server · CLI · .env placeholder expansion.

npm version npm downloads license platform node

Stop pasting tokens into every new Claude session. Store them once, reference them everywhere — including commit-safe .env files.

Quick install (one line)

curl -fsSL https://raw.githubusercontent.com/vaultry/claude-secrets/main/install.sh | bash

Or via npm:

npm install -g @vaultry/claude-secrets
claude-secrets-setup
claude mcp add claude-secrets --scope user -- claude-secrets-mcp

Related MCP server: SecureCode

Three interfaces

Interface	Who uses it	Policy-gated
MCP server	Claude Code sessions	Yes (per-project allowlist)
CLI `claude-secrets`	Your shell, apps, scripts	No (user has Keychain access)
`.env` placeholders	Any tool that reads .env	Via CLI

Store secrets

Store demo

Pipe from stdin (keeps the value out of shell history):

echo "ghp_xxxxx" | claude-secrets set GITHUB_TOKEN
op read "op://Private/Gitea/token" | claude-secrets set GITEA_TOKEN
claude-secrets set DB_PASSWORD              # interactive — type, Ctrl-D

Encrypted with AES-256-GCM, master key stored in macOS Keychain (syncs between Macs via iCloud Keychain).

Commit-safe `.env` files

dotenv demo

Replace real values with secret://NAME references. The .env file can now be committed to git safely — it contains only names, no credentials.

# .env
API_KEY=secret://GITHUB_TOKEN
DB_URL=postgres://app:secret://DB_PASSWORD@db.local/app
PORT=3000

Placeholder syntax: secret://NAME — URI-style, avoids bash parameter-expansion collisions. Names can contain A-Z, 0-9, _, ., -.

Expand placeholders

export demo

Resolve placeholders to real values at runtime:

eval "$(claude-secrets export)"                    # into current shell
claude-secrets export --format json > resolved.json
claude-secrets export --format dotenv > .env.resolved

claude-secrets export --file .env.staging         # different file
claude-secrets export --on-missing empty          # empty for missing refs

`--on-missing`	Behavior
`throw` (default)	Exit 1 with list of missing names
`empty`	Placeholder becomes empty string
`keep`	Placeholder left literal (`secret://NAME`)

Run a command with secrets

exec demo

claude-secrets exec -- pnpm dev                    # inject then run
claude-secrets exec -- node build.js
claude-secrets exec --file .env.prod -- npm run deploy

Secrets live only in the child process — not in the parent shell's environment, history, or ps output.

package.json scripts work seamlessly:

{
  "scripts": {
    "dev": "claude-secrets exec -- ts-node src/index.ts",
    "test": "claude-secrets exec --file .env.test -- vitest",
    "deploy": "claude-secrets exec --file .env.prod -- node deploy.js"
  }
}

MCP server (for Claude Code)

After registering with claude mcp add, Claude Code gets 6 tools under mcp__claude-secrets__*:

Tool	Policy check	Effect
`set_secret`	yes	Store/overwrite (requires allowlist)
`get_secret`	yes	Return value or `Denied`
`delete_secret`	yes	Remove or `Denied`
`list_secrets`	filter	`{total, visible, names}`
`search_secrets`	filter	Array of matches (regex, case-insensitive)
`input_secret`	yes	Native macOS dialog prompts user for value → stored directly. Value never passes through the model or chat.

`input_secret` — secure user input

Use case: Claude needs a token the user hasn't stored yet. Instead of asking "please paste your token in chat" (which leaks the value into transcripts, API logs, and plan files), Claude calls input_secret — a native macOS dialog pops up, user types the value, value goes straight from dialog to encrypted store without Claude ever seeing it.

Claude: "I need a GITEA_TOKEN to push that branch. May I prompt you?"
User: "yes"
Claude: [calls input_secret with name=GITEA_TOKEN]
→ macOS dialog appears on your screen (hidden input)
→ you type the token, press OK
→ value stored in encrypted vault
→ Claude gets back "OK: 'GITEA_TOKEN' stored"

The value never appears in chat, transcripts, or API traffic.

list and search only return names that pass the allowlist. total shows the real count — Claude knows more secrets exist but can't see their names from a non-authorized project.

Per-project allowlist — `.claude/secrets.yml`

Without this file: all MCP reads and writes blocked — prevents Claude in project A from reading or overwriting secrets from project B.

allow:
  - GITEA_TOKEN
  - GITHUB_*            # glob patterns supported
  - OP_SERVICE_*

Special values:

allow: "*"              # allow everything (not recommended)

allow:
  - GITEA_TOKEN
inject_values: true     # SessionStart hook injects values (opt-in)

secrets.yml is safe to commit — it contains names only.

SessionStart Hook (optional)

Inject available secret names into Claude's context at session start so Claude knows what's available without asking. Add to ~/.claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "claude-secrets-session-hook"
          }
        ]
      }
    ]
  }
}

With inject_values: true in secrets.yml, the hook also injects values — they appear in transcripts, history.jsonl, plan files, and API logs. Only use for short-lived tokens in trusted projects. The hook emits a visible warning when values are injected.

Slash commands for Claude Code

Two slash commands included in the package:

Command	Effect
`/secret-set <NAME>`	Native macOS dialog (hidden input) → stored via CLI
`/secret-get <NAME>`	CLI fetch → copied to clipboard (value never in chat)

Link them into Claude Code's commands directory:

ln -sf $(npm root -g)/@vaultry/claude-secrets/commands/secret-set.md ~/.claude/commands/secret-set.md
ln -sf $(npm root -g)/@vaultry/claude-secrets/commands/secret-get.md ~/.claude/commands/secret-get.md

(The one-line installer handles this automatically.)

Security model

Protects against

Master key outside the encrypted file — held in Keychain, user-locked
Per-project allowlist blocks cross-project leakage through Claude
AES-256-GCM — authenticated encryption, tamper detection
File mode 0600 — owner-only
Atomic writes (write-to-temp + rename) — no partial-state corruption on crash
.env with refs — commit-safe by construction
exec -- injection — secrets stay out of shell history and ps output

Know the trade-offs

inject_values: true puts values in Claude's system prompt → they appear in transcripts, history.jsonl, plan files, and API logs
CLI bypasses policy — anyone with your user ID and an unlocked Mac can read all secrets (correct: Keychain is what protects you as a user, policy protects Claude from itself)
Keychain ACL — after the first "Always Allow", node can read the key without a prompt
MCP writes are gated by allowlist since v0.1 — prevents cross-project overwrites

Not a defense against

Malicious local processes running as your user
Physical access to an unlocked Mac
A compromised Keychain (root-level malware)

CLI reference

claude-secrets help

  get <name>                         Print secret to stdout
  set <name> [value]                 Store secret (value from stdin if omitted)
  delete|rm <name>                   Delete a secret
  list|ls                            List all secret names
  search <pattern>                   Regex search (case-insensitive)

  export [--file .env]               Print 'export KEY=VAL' lines for shell eval
    [--format shell|dotenv|json]     Default: shell
    [--on-missing throw|empty|keep]  Default: throw

  exec [--file .env] -- <cmd...>     Run cmd with expanded env from .env
    [--on-missing throw|empty|keep]  Default: throw

Architecture

~/.claude/
└── secrets.encrypted                # AES-256-GCM, mode 0600

@vaultry/claude-secrets (installed)
├── dist/
│   ├── index.js                     # MCP server (stdio)
│   ├── crypto.js                    # AES-256-GCM + Keychain I/O
│   ├── store.js                     # atomic read/write secrets.encrypted
│   ├── policy.js                    # isAllowed() via secrets.yml
│   ├── dotenv.js                    # .env parser + placeholder expansion
│   └── bin/
│       ├── setup.js                 # init CLI
│       ├── session-hook.js          # SessionStart hook
│       └── cli.js                   # claude-secrets CLI
└── commands/                        # Claude Code slash commands

Encryption details

Algorithm: AES-256-GCM (authenticated encryption, tamper detection)
IV: 12 bytes, random per write
Key: 32 bytes, in macOS Keychain as service claude-secrets-mcp, account master-key
File format: {iv_b64}:{authtag_b64}:{ciphertext_b64}
Decrypted payload: JSON {name: value}
Writes: temp-file + rename, atomic on POSIX

Sync between Macs

iCloud Keychain auto-syncs the master key
Sync secrets.encrypted via Dropbox/iCloud Drive/git-crypt if needed — it's useless without the key

Requirements

macOS (uses the security CLI for Keychain access)
Node.js ≥ 18

Cross-platform support (Linux/Windows via keytar) is planned for v0.2.

Workflow example

cd ~/projects/new-thing
git init

# Secrets already stored? Check:
claude-secrets search 'GITEA|DB'

# Add new ones:
op read "op://Private/Gitea/token" | claude-secrets set GITEA_TOKEN
claude-secrets set DB_PASSWORD              # type, Ctrl-D

# Commit-safe .env:
cat > .env <<EOF
GITEA_TOKEN=secret://GITEA_TOKEN
DATABASE_URL=postgres://app:secret://DB_PASSWORD@localhost:5432/mydb
PORT=3000
EOF

# Let Claude read specific tokens (optional):
mkdir -p .claude
cat > .claude/secrets.yml <<EOF
allow:
  - GITEA_TOKEN
  - DB_PASSWORD
EOF

# Dev server with secrets injected:
claude-secrets exec -- pnpm dev

Troubleshooting

"Keychain entry not found" Setup wasn't run. Run claude-secrets-setup.

"Invalid ciphertext format" secrets.encrypted is corrupt or was encrypted with a different key. Restore from backup or delete and start over.

Keychain prompt on every read Normal on the first session after login. Check "Always Allow". If it keeps prompting: Keychain Access app → find claude-secrets-mcp → right-click → Access Control → add the node binary.

claude-secrets: command not found

export PATH="$(npm bin -g):$PATH"

MCP not visible in Claude

claude mcp list | grep claude-secrets      # should show "✓ Connected"

If not: restart the Claude session.

Secret in .env but expansion fails Check: claude-secrets get NAME — exists? Name match is case-sensitive. Placeholder syntax must be exactly secret:// (not @secrets: or ${secrets:}).

Uninstall

claude mcp remove claude-secrets --scope user
security delete-generic-password -s claude-secrets-mcp -a master-key
rm ~/.claude/secrets.encrypted
npm uninstall -g @vaultry/claude-secrets
rm -f ~/.claude/commands/secret-set.md ~/.claude/commands/secret-get.md
# Remove the session-hook line from ~/.claude/settings.json manually

License

Source-available under the Vaultry Source-Available License v1.0. Free for personal, educational, and internal use. Commercial use (resale, SaaS, bundled products) requires a separate commercial license — contact mail@jorisslagter.nl.

See LICENSE.md for full terms.

Made by Joris Slagter · Report an issue · npm

Available Tools

6 tools

delete_secretA

Delete a secret by name. Requires allowlist.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description reveals deletion behavior and permission requirement, but lacks details on side effects (e.g., irreversibility, cascading deletes) or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that conveys the essential action and a key prerequisite. No superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete tool with one parameter and no output schema, the description covers the basic action and a requirement. However, it lacks details on idempotency or handling of missing secrets, leaving some context gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description says 'by name', which implies the parameter is a name, but does not elaborate on format or constraints. Schema has no description, so the description adds minimal value beyond identifying it as the identifier.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'delete' and the resource 'secret by name', which distinguishes it from sibling tools like get_secret, list_secrets, etc. The purpose is immediately understandable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It mentions 'Requires allowlist', giving a precondition, but does not specify when to use this tool vs alternatives (e.g., set_secret). No guidance on when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_secretA

Read a secret value by name. Requires name to be whitelisted in project .claude/secrets.yml.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Secret name

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the authorization requirement (whitelisting), which is a behavioral trait. However, it does not mention side effects (none expected), rate limits, or response format, leaving some gaps for a complete picture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no fluff. It front-loads the action and then adds the prerequisite. Every sentence is necessary and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 parameter, no output schema), the description covers the core action and a critical prerequisite. However, it omits what the tool returns (e.g., the secret value in plaintext), which would be helpful for an agent without an output schema. Still, it is fairly complete for a simple read operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the only parameter 'name', so the baseline is 3. The description does not add any additional meaning beyond the schema's 'Secret name' description. No extra syntax, format, or constraints are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read a secret value by name', which is a specific verb+resource combination. It distinguishes from sibling tools like delete_secret, list_secrets, etc., which have different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a prerequisite (whitelisting) but does not explicitly state when to use this tool versus alternatives. Usage is implied by the action 'read' compared to siblings, but no when-not-to-use or explicit alternative naming is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

input_secretA

Prompt the user for a secret value via a native macOS dialog (hidden input), then store it. The value never passes through the model or the chat — it goes directly from the user's dialog into the encrypted store. Use this when you need a token, password, or API key the user has not yet stored. Requires name to be whitelisted in project .claude/secrets.yml.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Secret name to store under
`prompt`	No	Text shown in the dialog (e.g. 'Paste your GitHub token:')

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes key behavioral trait: value never passes through model or chat, goes directly to encrypted store. No annotations provided, so description carries full burden. Could mention whether it overwrites existing secrets or returns anything.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose. Every sentence adds essential information. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description gives sufficient context for a simple interaction tool. Could clarify that dialog blocks execution, but overall complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by noting name must be whitelisted in secrets.yml, which is not in schema. Also explains prompt parameter context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it prompts user for a secret via macOS dialog and stores it, using specific verb 'Prompt' and resource 'secret'. Distinguishes from siblings like get_secret, set_secret by emphasizing user interaction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage guidance: 'Use this when you need a token, password, or API key the user has not yet stored.' Also mentions prerequisite (name whitelisted). Could add explicit when-not-to-use, but inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_secretsA

List secret names visible to current project (filtered by .claude/secrets.yml allowlist).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Mentions filtering by allowlist, but lacks details on read nature, auth requirements, or result format. Adequate but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, efficient, front-loaded with key information. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple (no parameters, no output schema). Description covers purpose and filtering context. Could mention whether pagination exists, but not critical for a names-only list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so schema coverage is 100%. Baseline for zero parameters is 4. Description adds no parameter info, but none needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists secret names, with filtering by an allowlist. Verb 'list' with resource 'secret names' is specific. Distinguishes from siblings like delete_secret or set_secret by focusing on names only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description tells what it does but not when to use it over siblings like search_secrets or get_secret. No explicit when-not or alternatives, though sibling names hint at different actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_secretsA

Search secret names by regex pattern (case insensitive). Filtered by allowlist.

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses case-insensitive regex and allowlist filtering, but does not specify return format (names vs. full secrets), behavior on no match, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence front-loading the action and key constraints (regex, case insensitive, allowlist filter). No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-param tool with no output schema and no annotations, the description is mostly adequate. However, it lacks details on return values and error behavior, which would be helpful for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no description for 'pattern'). Description adds that it is a regex pattern and case insensitive, which provides essential semantic meaning beyond the schema's raw type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'Search', resource 'secret names', and method 'by regex pattern (case insensitive)'. It distinguishes from siblings like 'list_secrets' by specifying a regex search, and 'get_secret' by targeting names only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage: use when needing to find secret names matching a pattern. No explicit mention of when not to use or alternatives among siblings like 'list_secrets' or 'get_secret'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_secretA

Store a secret value. Creates or overwrites. Requires name to be whitelisted in project .claude/secrets.yml.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`value`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states 'Creates or overwrites' but does not disclose whether overwriting is destructive, authentication requirements, rate limits, or error behavior. Minimal behavioral insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences convey the core action and a key requirement. No redundant or superfluous information. Excellent front-loading of purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (2 params, no output schema, no annotations), the description should be more complete. Missing details: what happens if name is not whitelisted, overwrite behavior, return value, error handling, or data sensitivity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% with no parameter descriptions in the schema. The description only adds context for 'name' (must be whitelisted) but provides no meaning for 'value' beyond being the secret. Value lacks type, constraints, or formatting guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Store a secret value' and mentions 'Creates or overwrites.' It distinguishes from siblings like delete_secret, get_secret, list_secrets, etc., by focusing on storage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a prerequisite: 'Requires name to be whitelisted in project .claude/secrets.yml.' This gives clear context for when to use the tool, though it does not explicitly exclude alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct action on secrets (delete, get, input, list, search, set) with no overlap. An agent can clearly distinguish between them.

Naming Consistency5/5

All tools follow a consistent verb_secret pattern using snake_case, making them predictable and easy to understand.

Tool Count5/5

Six tools cover the essential operations for secret management—CRUD plus search and user input—without being excessive or insufficient.

Completeness5/5

The set covers the full lifecycle of secrets: create/update (set), read (get), delete, list, search, and user input. There are no obvious gaps for a basic secret store.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

nexsus
io.github.dbnexsus
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Knowledge & Memory RAG Systems
2
mcp
ai.butlerbrain
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Knowledge & Memory RAG Systems Workplace & Productivity
2
JustOnce
ai.justonce
Persistent memory for AI assistants — one shared, OAuth-secured vault for every MCP client.
Knowledge & Memory Security
1
MemoryRouter A
ai.memoryrouter
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Knowledge & Memory Search
101

Related MCP Servers

Melchizedek
Knowledge & Memory RAG Systems Search
louis49
A
license
A
quality
B
maintenance
Persistent memory for Claude Code. Automatically indexes every conversation and provides production-grade hybrid search (BM25 + vectors + reranker) via MCP tools. 100% local, zero config, zero API keys, zero invoice.
Updated 2 months ago (2026-06-21 05:22 UTC)
16
57
7
MIT
SecureCode
Security Developer Tools
juanisidoro
A
license
A
quality
D
maintenance
Secrets vault for Claude Code. Encrypt API keys, tokens and passwords with AES-256. Full audit logs, MCP access rules, and zero-knowledge mode. Secrets never appear in chat.
Updated 6 months ago (2026-03-17 18:10 UTC)
17
78
1
MIT
Kova Mind MCP Serverofficial
Knowledge & Memory Security
KovaMind
A
license
A
quality
C
maintenance
Enables AI memory persistence and secure credential management via vault tools for MCP-compatible clients like Claude Desktop, Cursor, and VS Code.
Updated 23 days ago (2026-08-12 02:29 UTC)
12
27
MIT
Secret Vault MCP Server
Security Developer Tools
sam-ueckert
F
license
Not graded
quality
D
maintenance
AES-256-GCM encrypted local secret storage exposed as MCP tools, with secrets captured via native OS dialogs and never passing through the LLM API.
Updated 3 months ago (2026-06-08 16:54 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vaultry/claude-secrets'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@vaultry/claude-secrets

Quick install (one line)

Three interfaces

Store secrets

Commit-safe .env files

Expand placeholders

Run a command with secrets

MCP server (for Claude Code)

input_secret — secure user input

Per-project allowlist — .claude/secrets.yml

SessionStart Hook (optional)

Slash commands for Claude Code

Security model

Protects against

Know the trade-offs

Not a defense against

CLI reference

Architecture

Requirements

Workflow example

Troubleshooting

Uninstall

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Kova Mind MCP Serverofficial

Latest Blog Posts

MCP directory API

Commit-safe `.env` files

`input_secret` — secure user input

Per-project allowlist — `.claude/secrets.yml`