Vaulted MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VAULTED_BASE_URL | No | Vaulted API base URL (for self-hosted instances) | https://vaulted.fyi |
| VAULTED_ALLOWED_DIRS | No | Comma-separated directories accessible for file-based input sources (extends CWD) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_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. |
| view_secretA | 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. |
| check_statusA | 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. |
| list_secretsA | List previously shared secrets and their current status — view counts, expiry, and whether they've been consumed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| share-secret | Share a secret securely via an encrypted, self-destructing link |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
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.
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.
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.
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.