volta-mcp-server
This server enables secure, burn-after-read encrypted note sharing between AI agents and users, preventing sensitive information from appearing in chat history.
Create encrypted notes (
create_volta_note): Encrypt and store sensitive content (up to 2KB) using AES-256-GCM, receiving a one-time URL to share — the note is permanently destroyed after a single readRead and destroy notes (
read_volta_note): Retrieve decrypted content of a Volta note by providing its full URL (including the#fragmentdecryption key), permanently deleting it after retrievalSecure credential exchange: Safely transfer API keys, passwords, and credentials between agents and users without exposing them in conversation logs — works in both directions (agent-to-user and user-to-agent)
End-to-end encryption: All encryption/decryption happens locally; only ciphertext is stored on the Internet Computer, so even a compromised server cannot read the data
Ephemeral storage: Notes are automatically destroyed after a single read, or expire after 7 days if unread
Cross-platform: Compatible with Claude Code, Claude Desktop, Cursor, Windsurf, Cline, Continue.dev, and other MCP-compatible clients
Provides tools for storing and retrieving encrypted notes on Internet Computer (ICP) canisters, enabling burn-after-read functionality where ciphertext is permanently destroyed after first access
@voltanotes/mcp
MCP server for Volta Notes — create and read burn-after-read encrypted notes from any AI agent.
Notes are end-to-end encrypted using AES-256-GCM. The decryption key lives only in the URL fragment — it is never sent to any server. Notes are stored on the Internet Computer and permanently destroyed after a single read.
Why
AI agents regularly need sensitive information at runtime — API keys, passwords, credentials. Today, users paste these into chat where they're stored permanently in conversation history.
With this MCP server, the pattern becomes:
User creates a note at voltanotes.com and sends the one-time URL
Agent calls
read_volta_note— secret returned, note permanently destroyedNothing sensitive ever appears in chat history
Or in reverse — an agent can use create_volta_note to send credentials to a user via a self-destructing link.
Related MCP server: Vaulted MCP Server
Quick Start
Claude Code (CLI & Desktop App)
Step 1 — Install globally:
npm install -g @voltanotes/mcpStep 2 — Register the server:
claude mcp add -s user volta -- node $(npm root -g)/@voltanotes/mcp/dist/index.jsThat's it. Restart Claude Code and the create_volta_note and read_volta_note tools will be available.
Why
claude mcp addinstead of editing config files? Claude Code reads MCP servers from its own registry, not from~/.claude/mcp.json. Using the CLI ensures the server is registered correctly. The-s userflag makes it available across all projects.
nodenot found? Use the full path: replacenodewith the output ofwhich node(e.g./usr/local/bin/node).
Claude Desktop (Standalone)
Add to your claude_desktop_config.json:
{
"mcpServers": {
"volta": {
"command": "npx",
"args": ["-y", "@voltanotes/mcp"]
}
}
}Other MCP-compatible clients
The npx config above works with any client that supports the standard command/args MCP format — including Cursor, Windsurf, Cline, Continue.dev, and others. Check your client's MCP documentation for where to add server config.
Hermes Agent (Nous Research)
Volta MCP works with Hermes Agent via its MCP integration. Add the server to your Hermes config (~/.hermes/config.yaml):
mcp:
servers:
- name: volta
command: npx
args:
- "-y"
- "@voltanotes/mcp"Restart Hermes and the create_volta_note and read_volta_note tools will be available to your agent.
Agent-to-agent use case: Hermes agents running autonomously often need to pass credentials between workflows without exposing them in logs or memory. Volta Notes is purpose-built for this — one agent creates a note, passes the one-time URL to the next, and the secret is destroyed on read. Nothing persists in conversation history or tool output logs.
See Hermes MCP documentation for full configuration options.
Windows (Claude Code CLI)
The $(npm root -g) syntax doesn't work in PowerShell or CMD. Use this instead:
claude mcp add -s user volta -- node "%APPDATA%\npm\node_modules\@voltanotes\mcp\dist\index.js"Or use the Claude Desktop / npx method above, which works cross-platform.
Tools
create_volta_note
Creates an encrypted note and returns a one-time URL.
Parameter | Type | Description |
| string | Secret content to encrypt (max 2 KB) |
Returns: A voltanotes.com URL. The recipient opens it once, reads the content, and it's gone forever.
read_volta_note
Reads and permanently destroys a Volta note.
Parameter | Type | Description |
| string | Full Volta URL including |
Returns: The decrypted note content. The note is permanently deleted from the canister — a second read will fail.
Agent Prompt Snippet
Add this to any agent's system prompt to enable secure credential handoff:
When you need a secret from the user (API key, password, credentials):
1. Ask them to go to voltanotes.com and paste the secret into the note field
2. They'll get a one-time URL — ask them to send it to you
3. Use the read_volta_note tool with that URL to retrieve the secret
The secret is permanently destroyed after you read it — it never appears in chat history.Security Model
AES-256-GCM encryption happens locally before anything is sent to the canister
The encryption key exists only in the URL fragment (
#...) — browsers and servers never transmit fragmentsThe ICP canister stores only ciphertext — even if compromised, all data is unreadable
Notes are destroyed on first read. Unread notes expire after 7 days.
No accounts, no login, no tracking
How It Works
Agent calls create_volta_note("secret-api-key-123")
→ Local: generate AES-256 key + encrypt
→ ICP canister: store ciphertext → returns noteId
→ Return URL: voltanotes.com/r/{noteId}#{key}
User opens URL → read gate → clicks "Read note"
→ Browser: fetch ciphertext from canister (canister deletes it)
→ Browser: decrypt using key from # fragment
→ Display plaintext — note is gone foreverTroubleshooting
Check if the server is connected
claude mcp listYou should see volta: ... ✓ Connected. If not, see below.
Server not showing up
Did you use
claude mcp add? Editing~/.claude/mcp.jsonmanually won't work — Claude Code reads servers from its own registry. Always useclaude mcp addto register servers.Is
nodeon your PATH? Claude Code's shell has a minimal PATH. Ifnodeisn't found, use the full path:claude mcp add -s user volta -- $(which node) $(npm root -g)/@voltanotes/mcp/dist/index.jsRestart required. After adding or changing an MCP server, fully restart Claude Code (quit and reopen).
How do I know if the server started?
The server logs Volta MCP server started to stderr on successful startup. Run claude mcp list to check connection status.
Requirements
Node.js 18+ (uses built-in Web Crypto API)
License
MIT — Unprompted Labs
Available Tools
2 toolscreate_volta_noteA
Creates a Volta secure note and returns a one-time URL. Use this to send sensitive information to a user — they open the link once, read it, and it's gone. Useful for sharing generated passwords, private keys, or any sensitive output.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The secret content to encrypt and store. Maximum 2,048 characters. Will be AES-256-GCM encrypted before leaving this machine. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It successfully explains the critical one-time/self-destruct nature ('gone' after opening) and return value (one-time URL). Minor gap: doesn't mention expiration timeouts, rate limits, or specific return structure location.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly constructed sentences with zero waste: sentence 1 states function+output, sentence 2 explains the usage pattern, sentence 3 provides examples. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema exists, the description adequately compensates by stating the tool 'returns a one-time URL'. For a single-parameter creation tool, this covers the essential missing output information. Could be improved by specifying URL expiration behavior or exact return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with detailed technical description. The description adds semantic value by specifying what content belongs in the parameter ('generated passwords, private keys, sensitive output'), helping the agent map user intent to the 'content' field effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with specific verb 'Creates' + resource 'Volta secure note' and immediately distinguishes the core mechanism ('returns a one-time URL'). This clearly differentiates it from sibling 'read_volta_note' by establishing this as the creation/entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('send sensitive information to a user'), describes the complete UX lifecycle ('open the link once, read it, and it's gone'), and provides concrete examples ('generated passwords, private keys'). This gives clear selection criteria against the read sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_volta_noteA
Reads a Volta secure note and permanently destroys it. Call this when a user sends you a voltanotes.com URL containing sensitive information. The note content is returned once — it cannot be recovered after this call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full Volta note URL including the #fragment key, e.g. https://app.voltanotes.com/r/abc12345#encryptionKeyHere |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excellently discloses critical behavioral traits: the destructive nature ('permanently destroys'), one-time access ('returned once'), and irreversibility ('cannot be recovered').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly constructed sentences with zero waste: first states the core action, second provides the usage trigger, and third explains the critical one-time behavioral constraint. Information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking annotations and an output schema, the description adequately covers the return value behavior ('note content is returned once') and compensates for missing safety annotations by explicitly describing the destruction. Could optionally note authentication requirements or error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed example URL in the schema description. The description references the URL in context ('sends you a voltanotes.com URL') but does not add semantic meaning beyond what the schema already provides, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Reads' and 'destroys') with the resource ('Volta secure note') and clearly distinguishes from sibling tool create_volta_note by emphasizing consumption/destruction versus creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Call this when a user sends you a voltanotes.com URL containing sensitive information'), though it does not explicitly name the sibling tool as an alternative for creation workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The tools have clearly distinct purposes with no functional overlap: one creates secure notes while the other consumes them. An agent can easily distinguish between generating a new URL versus retrieving and destroying an existing note.
Both tools follow a consistent verb_noun pattern using snake_case (create_volta_note, read_volta_note), with identical resource naming ('volta_note') and parallel grammatical structure.
While two tools falls slightly below the typical optimal range, it is reasonable for this narrowly scoped one-time secret service where only creation and retrieval operations are relevant to the security model.
The tools cover the essential lifecycle (create and read-once-destroy) for secure note sharing. Minor potential gaps include missing expiration configuration or metadata retrieval, though these may be intentionally excluded for security.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Share text, markdown, code, or HTML as auto-expiring links
Paste short text, get a shareable URL. Read any by slug; create with an API key.
Deploy HTML and Markdown as live URLs. Create, search, update, and manage pastes from any AI agent.
Publish plain-text posts at a public URL. No account, no sign-up.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceSelf-hosted, zero-knowledge encrypted, self-destructing secrets for secure agent-to-agent coordination3AGPL 3.0
- AlicenseAqualityDmaintenanceShare encrypted, self-destructing secrets from your AI agent. Zero-knowledge E2E encryption. Agent-blind input sources (env:, file:, dotenv:) keep secrets out of LLM context.4201MIT
- FlicenseNot gradedqualityDmaintenanceEnables 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.1
- AlicenseNot gradedqualityAmaintenanceEnables sharing and reading encrypted files (text, images, logs) for AI workflows, with automatic 24-hour expiration and host-blind security.35156MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/iamredmh/volta-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server