Which integrations are available for this server?

Provides integration with Windsurf (Codeium's IDE), enabling secure secret sharing and management through the MCP protocol within the development environment. Supports agent-blind reading of .env file keys, allowing users to securely share environment variables without exposing the actual values to the LLM. Enables secure sharing of Stripe API keys and other sensitive Stripe credentials through encrypted, self-destructing links without exposing the actual values in conversation history.

de en es ja ko ru zh

Vaulted MCP Server

by vaulted-fyi

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

@vaulted/mcp-server

npm version license

Share encrypted, self-destructing secrets directly from Claude Desktop, Cursor, Windsurf, and any MCP-compatible AI tool.

🔒 Zero-knowledge E2E encryption (AES-256-GCM, key never sent to server)
🙈 Agent-blind input: share env vars, files, and .env keys without exposing them in context
🛠️ 4 tools: create_secret, view_secret, check_status, list_secrets
📋 Local history with live status tracking
💻 Works with Claude Desktop, Cursor, Windsurf, Claude Code, VS Code

The headline feature: sensitive values are resolved locally and never passed through the LLM. When you ask your agent to share an environment variable or file, the MCP server reads the value directly from your machine — the agent only ever sees the secure link, not the secret itself.

"Share the value of my STRIPE_SECRET_KEY env var"
→ Agent passes: env:STRIPE_SECRET_KEY  (never sees the value)
→ Server resolves it locally, encrypts, returns the link

This means sensitive values never appear in your conversation history or the LLM's context.

Related MCP server: enigmagent-mcp

Installation

Requires Node.js ≥ 18.

Zero-install via npx:

npx -y @vaulted/mcp-server

Or install globally:

npm install -g @vaulted/mcp-server
vaulted-mcp-server

Quick start

Add to your MCP host config and restart the application. Your agent will have access to all 4 Vaulted tools immediately.

{
  "mcpServers": {
    "vaulted": {
      "command": "npx",
      "args": ["-y", "@vaulted/mcp-server"]
    }
  }
}

Configuration

Claude Desktop

File: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "vaulted": {
      "command": "npx",
      "args": ["-y", "@vaulted/mcp-server"]
    }
  }
}

Cursor

File: ~/.cursor/mcp.json

{
  "mcpServers": {
    "vaulted": {
      "command": "npx",
      "args": ["-y", "@vaulted/mcp-server"]
    }
  }
}

Windsurf

File: ~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "vaulted": {
      "command": "npx",
      "args": ["-y", "@vaulted/mcp-server"]
    }
  }
}

Claude Code

File: .mcp.json in your project root (or ~/.claude/.mcp.json globally):

{
  "mcpServers": {
    "vaulted": {
      "command": "npx",
      "args": ["-y", "@vaulted/mcp-server"]
    }
  }
}

VS Code

File: .vscode/mcp.json

{
  "servers": {
    "vaulted": {
      "command": "npx",
      "args": ["-y", "@vaulted/mcp-server"]
    }
  }
}

Any other MCP client

Run npx @vaulted/mcp-server as a stdio transport. The server uses the standard MCP stdio protocol.

Optional flags

Flag	Default	Description
`--base-url`	`https://vaulted.fyi`	Vaulted API base URL (for self-hosted instances)
`--allowed-dirs`	(none)	Comma-separated directories accessible for file-based input sources (extends CWD)

Pass flags via the args array:

{
  "mcpServers": {
    "vaulted": {
      "command": "npx",
      "args": ["-y", "@vaulted/mcp-server", "--base-url", "https://your-instance.example.com"]
    }
  }
}

Multiple allowed directories:

{
  "mcpServers": {
    "vaulted": {
      "command": "npx",
      "args": ["-y", "@vaulted/mcp-server", "--allowed-dirs", "/home/user/secrets,/tmp/creds"]
    }
  }
}

Tools reference

`create_secret`

Encrypt and store a secret, returns a shareable self-destructing link.

Parameter	Type	Default	Description
`content`	string	required	The secret to encrypt (max 1000 chars). Supports agent-blind prefixes.
`max_views`	`"1"` \| `"3"` \| `"5"` \| `"10"`	`"1"`	Views before self-destruct
`expiry`	`"1h"` \| `"2h"` \| `"6h"` \| `"12h"` \| `"24h"` \| `"3d"` \| `"7d"` \| `"14d"` \| `"30d"`	`"24h"`	Time until expiration
`passphrase`	string	(none)	Optional passphrase protection
`label`	string	(none)	Human-readable label for local history

Returns: { success: true, data: { url, statusUrl, expiresIn, maxViews, passphraseProtected }, message }

`view_secret`

Retrieve and decrypt a secret from a Vaulted URL. Defaults to opening in the browser — use output_mode to keep the decrypted value out of the conversation.

Parameter	Type	Default	Description
`url`	string	(one req.)	Full Vaulted URL including the `#` fragment
`secret_id`	string	(one req.)	Secret ID (alternative to `url`)
`encryption_key`	string	(with secret_id)	Encryption key from URL fragment (required with `secret_id`)
`output_mode`	`"browser"` \| `"clipboard"` \| `"file"` \| `"direct"`	`"browser"`	Where to send the decrypted value
`file_path`	string	(none)	Required when `output_mode` is `"file"`
`passphrase`	string	(none)	Required for passphrase-protected secrets

Output modes:

browser — opens the secret URL in your default browser (decryption happens in-browser, value stays out of agent context)
clipboard — copies decrypted value to clipboard, nothing returned to agent
file — writes decrypted value to file_path, nothing returned to agent
direct — returns decrypted value in the response (use with care — value enters agent context)

Returns: Depends on output_mode. Browser/clipboard/file modes confirm success without returning the plaintext.

`check_status`

Check how many times a secret has been viewed and whether it's still active. Does not consume a view.

Parameter	Type	Default	Description
`url`	string	(one req.)	Status URL (e.g., `https://vaulted.fyi/s/<id>/status?token=...`)
`secret_id`	string	(one req.)	Secret ID (alternative to `url`)
`status_token`	string	(with id)	Status token from secret creation (required with `secret_id`)
`previousViews`	number	(none)	Pass the last known view count to detect new views since last check. When the count increases, the response includes "New view detected!"

Returns: { success: true, data: { views, maxViews, status, expiresAt }, message }

`list_secrets`

Show all locally tracked secrets with their live status fetched from the API.

Parameter	Type	Description
(none)	—	No parameters

Returns: { success: true, data: { entries: [...], suggestedAction? }, message }

suggestedAction is included when unconsumed active secrets exist, prompting you to use check_status to monitor them.

Response format

All tools use a consistent response shape:

// Success
{ "success": true, "data": { /* tool-specific */ }, "message": "Human-readable summary" }

// Error
{ "success": false, "error": { "code": "SECRET_EXPIRED", "message": "...", "suggestion": "..." } }

Error codes: SECRET_EXPIRED, SECRET_CONSUMED, PASSPHRASE_REQUIRED, ENV_VAR_NOT_FOUND, FILE_NOT_FOUND, PATH_TRAVERSAL_BLOCKED, DOTENV_KEY_NOT_FOUND, API_UNREACHABLE, API_ERROR, ENCRYPTION_FAILED, FILE_WRITE_ERROR, INVALID_INPUT

Examples

Create a secret

"Share this API key securely: sk-abc123"

→ Returns a one-time link in the chat. Share it via Slack, email, or a ticket.

"Share the value of my GITHUB_TOKEN env var securely"

→ Agent passes env:GITHUB_TOKEN to the tool. The server reads the value locally. The agent never sees the token.

"Share the contents of ~/.ssh/id_rsa.pub securely"

→ Agent passes file:~/.ssh/id_rsa.pub. File is read locally and encrypted before the link is returned.

"Share the DATABASE_URL from my .env.local"

→ Agent passes dotenv:.env.local:DATABASE_URL. The specific key is parsed and encrypted. Other values in the file are never read.

View a secret in the browser

"Open this secret: https://vaulted.fyi/s/abc123#key..."

→ Browser opens with the decrypted content. The value never enters the conversation.

View a secret to clipboard

"Retrieve this secret to my clipboard: https://vaulted.fyi/s/abc123#key..."

→ Decrypted value is copied to clipboard. Nothing sensitive is returned in the chat.

Save a secret to a file

"Save this secret to /tmp/creds.txt: https://vaulted.fyi/s/abc123#key..."

→ Decrypted value is written to /tmp/creds.txt. Nothing sensitive is returned in the chat.

View a secret directly (returns value to agent)

"Retrieve this secret and return the value to me: https://vaulted.fyi/s/abc123#key..."

→ Decrypted value is returned in the response. Use only when you need the value in the conversation — it will appear in your chat history.

Check whether a secret has been viewed

"Has my secret been viewed yet?"

→ Returns view count, max views, and expiry. Does not consume a view.

Poll for new views

"Let me know when someone views my secret — previous view count was 0"

→ Pass previousViews: 0. When the count increases, the response includes "New view detected!"

List recent secrets

"What secrets have I shared recently?"

→ Returns your local history with live status from the API — view counts, remaining views, and expiry for each.

Agent-blind input sources

The content parameter of create_secret supports prefixes that instruct the server to resolve the value locally before encrypting. The resolved value is never passed back to the agent.

Prefix	Example	Resolves to
(none)	`the plain value`	Literal string
`env:`	`env:STRIPE_SECRET_KEY`	`process.env.STRIPE_SECRET_KEY`
`file:`	`file:/home/user/.ssh/id_rsa`	Contents of the file at that path
`dotenv:`	`dotenv:.env.local:DATABASE_URL`	Value of `DATABASE_URL` in `.env.local`

Path security: File and dotenv paths are validated against process.cwd() and any --allowed-dirs you configure. Symlinks pointing outside allowed directories are rejected with PATH_TRAVERSAL_BLOCKED.

Output modes that keep secrets out of context: Use browser, clipboard, or file output modes for view_secret — the decrypted value is delivered directly to you without entering the agent's response or conversation history.

Security model

End-to-end encrypted: AES-256-GCM encryption runs locally via @vaulted/crypto. The server never sees plaintext.
Key in URL fragment: The encryption key lives only in the # fragment of the URL — never sent to any server, never logged.
Zero-knowledge server: vaulted.fyi stores only ciphertext. It cannot decrypt your secrets.
Self-destructing: Secrets are deleted when max views are reached or TTL expires — whichever comes first.
No accounts, no telemetry: Anonymous usage. No API keys required.
Agent-blind by design: Input source prefixes (env:, file:, dotenv:) ensure sensitive values never pass through the LLM.

Learn more at vaulted.fyi/security.

Contributing

git clone https://github.com/vaulted-fyi/vaulted-mcp-server
cd vaulted-mcp-server
npm install
npm test

License

MIT

Available Tools

4 tools

check_statusCheck StatusA

Read-onlyIdempotent

Check the status of a previously shared secret — how many times it's been viewed, whether it's still active, and when it expires. Does not consume a view. Optionally pass previous_views to detect new views since last check.

ParametersJSON Schema

Name	Required	Description
`url`	No
`secret_id`	No
`status_token`	No
`previousViews`	No	Last known view count. When provided, the response message will indicate if new views have occurred since this value.

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds valuable context beyond this by specifying that it 'does not consume a view' (a key behavioral trait not covered by annotations) and explains the effect of the 'previousViews' parameter on response messaging. No contradictions with annotations are present.

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 efficiently structured in two sentences: the first covers the core purpose and key details, and the second explains optional parameter usage. Every sentence adds value without redundancy, making it front-loaded and appropriately concise for the tool's complexity.

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 tool's moderate complexity (4 parameters, no output schema), the description is mostly complete: it covers purpose, usage, and key behavioral traits. However, it lacks details on return values (e.g., what specific data is returned about views, active status, expiration) and does not fully explain all parameters, leaving some gaps in contextual understanding.

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?

With only 25% schema description coverage (only 'previousViews' has a description), the description compensates by explaining the purpose of 'previousViews' ('to detect new views since last check'), adding meaningful context. However, it does not clarify the semantics of 'url', 'secret_id', or 'status_token', leaving some parameters under-explained.

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 specific action ('check the status') and resource ('previously shared secret'), with detailed scope including view count, active status, and expiration. It explicitly distinguishes from sibling 'view_secret' by noting 'does not consume a view', making the purpose unambiguous and differentiated.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: it specifies when to use this tool (to check status without consuming a view) versus alternatives (implied that 'view_secret' would consume a view). It also mentions optional use of 'previous_views' parameter for detecting new views, giving clear context for parameter application.

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

create_secretCreate SecretA

Create a secure, self-destructing link for sharing sensitive data like passwords, API keys, or credentials. The secret is encrypted end-to-end — the server never sees plaintext. Supports reading secrets from environment variables, files, or .env files without exposing them in the conversation. Optionally provide a label to identify the secret in your history.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	The secret content to encrypt and share. Max 1000 characters.
`max_views`	No	Maximum number of times the secret can be viewed before self-destructing. Defaults to 1.
`expiry`	No	How long before the secret expires. Defaults to 24h.
`passphrase`	No	Optional passphrase for additional protection. The recipient will need this passphrase to view the secret.
`label`	No	Optional label to identify this secret in your history (e.g. 'stripe-key', 'db-password').

TDQS

A4.2/5.0

Behavior4/5

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

The description adds valuable behavioral context beyond annotations: it explains the self-destructing nature, end-to-end encryption, server's inability to see plaintext, and how secrets can be read from various sources. While annotations cover basic safety (readOnlyHint=false, destructiveHint=false), the description provides important operational details about security and data 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 efficiently structured with three sentences that each add distinct value: purpose statement, security explanation, and usage guidance. It's front-loaded with the core functionality and contains no redundant information. Every sentence earns its place.

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?

For a creation tool with good annotations and comprehensive schema coverage, the description provides solid context about security, self-destruction, and input methods. The main gap is the lack of output schema, so the description doesn't explain what gets returned (e.g., a shareable link). However, given the tool's complexity and the schema's thoroughness, it's mostly complete.

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?

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description mentions 'label' and implies content handling from various sources, but doesn't add significant semantic meaning beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

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 specific action ('create a secure, self-destructing link') and resource ('secret'), and distinguishes it from siblings by focusing on creation rather than checking, listing, or viewing secrets. It provides concrete examples of what can be shared (passwords, API keys, credentials).

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 clear context about when to use this tool ('for sharing sensitive data') and mentions alternative input methods ('reading secrets from environment variables, files, or .env files'). However, it doesn't explicitly state when NOT to use it or directly compare it to sibling tools like list_secrets or view_secret.

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

list_secretsList SecretsA

Read-onlyIdempotent

List previously shared secrets and their current status — view counts, expiry, and whether they've been consumed.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds useful behavioral context beyond annotations by specifying what information is returned (view counts, expiry, consumption status), which helps the agent understand the output format and scope. No contradiction with annotations.

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, efficient sentence that front-loads the core action ('List previously shared secrets') and adds essential details ('current status — view counts, expiry, and whether they've been consumed') without waste. Every word contributes to understanding the tool's function.

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 tool's low complexity (0 parameters, no output schema) and rich annotations (readOnly, non-destructive, idempotent), the description is complete enough for an agent to use it correctly. It explains what the tool does and what information it provides, though it could mention pagination or sorting if relevant, but isn't required for basic understanding.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's purpose and output. Baseline is 4 for zero parameters, as it avoids unnecessary details.

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 ('List') and resource ('previously shared secrets') with specific scope details ('view counts, expiry, and whether they've been consumed'). It distinguishes from sibling tools like 'create_secret' (creation) and 'view_secret' (single secret) by emphasizing listing multiple secrets with status information.

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 implies usage for viewing status of multiple secrets, suggesting when to use it (to see list with status details). However, it doesn't explicitly state when NOT to use it or mention alternatives like 'view_secret' for single secrets or 'check_status' for status checks without listing. The context is clear but lacks explicit exclusions or comparisons.

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

view_secretView SecretA

Destructive

Retrieve and decrypt a secret from a Vaulted secure link. The secret may have view limits and will be destroyed after the maximum views are reached. By default opens in the browser for security — use output_mode to copy to clipboard, save to file, or return directly.

ParametersJSON Schema

Name	Required	Description
`url`	No	Full Vaulted URL (e.g., https://vaulted.fyi/s/abc123#key). Preferred over separate ID + key.
`secret_id`	No	Secret ID (alternative to URL). Must be paired with encryption_key.
`encryption_key`	No	Encryption key (alternative to URL). Must be paired with secret_id.
`output_mode`	No	How to deliver the secret. browser (default): opens the link in your browser — decryption happens in the web app. direct: returns decrypted content in the tool response. clipboard: copies decrypted content to the system clipboard (content omitted from response). file: writes decrypted content to file_path (content omitted from response).
`passphrase`	No	Passphrase to decrypt a passphrase-protected secret
`file_path`	No	File path for file output mode (required when output_mode is "file").

TDQS

A4.4/5.0

Behavior5/5

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

The description adds significant behavioral context beyond annotations: it discloses that secrets may have view limits and will be destroyed after maximum views (explaining destructiveHint), specifies default browser behavior for security, and describes output_mode options. This enriches the agent's understanding of side effects and operational details that annotations alone don't cover.

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 efficiently structured in two sentences: the first states the core purpose and key behavioral traits (view limits, destruction), and the second explains the default and alternative output modes. Every sentence adds essential information with zero waste or redundancy.

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 tool's complexity (destructive operation, multiple parameters, no output schema), the description is largely complete: it covers purpose, key behaviors, and output options. However, it lacks details on error handling, response format for 'direct' mode, or how view limits are tracked, leaving minor gaps for the agent.

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?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, mentioning output_mode options briefly but not providing additional semantics or usage nuances for parameters like url vs. secret_id/encryption_key alternatives.

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 specific action ('retrieve and decrypt') and resource ('a secret from a Vaulted secure link'), distinguishing it from siblings like 'create_secret' (creation) and 'list_secrets' (listing). It goes beyond the name/title by specifying the decryption aspect and Vaulted source.

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 clear context for usage ('retrieve and decrypt a secret') and mentions default behavior (opens in browser) and alternatives via output_mode. However, it doesn't explicitly state when to use this tool versus siblings like 'check_status' or 'list_secrets', nor does it provide exclusions or prerequisites for usage.

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.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: check_status monitors secret usage, create_secret generates new secrets, list_secrets provides an overview of existing secrets, and view_secret retrieves and decrypts secrets. The descriptions clearly differentiate between monitoring, creation, listing, and retrieval actions.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (check_status, create_secret, list_secrets, view_secret) with clear, descriptive names that accurately reflect their functions. There are no deviations in naming conventions across the set.

Tool Count5/5

With 4 tools, this server is well-scoped for managing secure secrets, covering the essential CRUD-like operations: create, list, view, and check status. Each tool earns its place without redundancy or bloat, making it easy for agents to navigate.

Completeness5/5

The tool set provides complete coverage for the secret-sharing domain: create_secret handles creation, list_secrets and check_status cover monitoring and status, and view_secret handles retrieval. There are no obvious gaps, as all lifecycle stages (creation, viewing, monitoring, expiration) are addressed.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

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

hush A
com.royashbrook
A secret store for AI agents: the agent never sees the plaintext.
Security AI & Machine Learning
1217
Stashbase
io.github.stashbase
Secrets for developers and agents—secure context and workflows without exposing secret values.
Security Developer Tools
1
Hive Secrets A
io.github.srotzin
Encrypted secret store and rotation for autonomous agent credentials
Security Autonomous Agents
2
seekrit — secrets for agents A
dev.seekrit
Encrypted store for API keys and database URLs your code needs. Use them without reading them.
Security Agent Orchestration
402

Related MCP Servers

zKettle
Autonomous Agents Security
benderterminal
A
license
Not graded
quality
C
maintenance
Self-hosted, zero-knowledge encrypted, self-destructing secrets for secure agent-to-agent coordination
Updated 6 months ago (2026-03-03 22:41 UTC)
3
AGPL 3.0
enigmagent-mcp
Security Developer Tools
Agnuxo1
A
license
A
quality
D
maintenance
Local AES-256-GCM encrypted vault for AI agents. Resolve {{PLACEHOLDER}} secrets in prompts at runtime — LLMs never see real API keys. Argon2id key derivation, zero cloud.
Updated 4 months ago (2026-04-26 17:07 UTC)
2
84
2
MIT
Credential Vault MCP
Security Autonomous Agents
CipherSatoru
A
license
Not graded
quality
C
maintenance
Enables secure credential storage for AI agents by encrypting secrets and providing agent-invisible references, ensuring sensitive data never leaks to the model.
Updated 4 months ago (2026-05-16 13:38 UTC)
MIT
SecureNote.link MCP Server
Security
jackalterman
F
license
Not graded
quality
D
maintenance
Enables AI agents to create end-to-end encrypted, self-destructing notes that can be securely shared via a one-click link, ensuring secrets are never stored in plain text in chat history.
Updated 6 months ago (2026-03-08 01:43 UTC)
1

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/vaulted-fyi/vaulted-mcp-server'

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

@vaulted/mcp-server

Agent-blind secret sharing

Installation

Quick start

Configuration

Claude Desktop

Cursor

Windsurf

Claude Code

VS Code

Any other MCP client

Optional flags

Tools reference

create_secret

view_secret

check_status

list_secrets

Response format

Examples

Create a secret

Agent-blind: share an environment variable

Agent-blind: share a file

Agent-blind: share a key from a .env file

View a secret in the browser

View a secret to clipboard

Save a secret to a file

View a secret directly (returns value to agent)

Check whether a secret has been viewed

Poll for new views

List recent secrets

Agent-blind input sources

Security model

Contributing

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`create_secret`

`view_secret`

`check_status`

`list_secrets`