Skip to main content
Glama
iamredmh

volta-mcp-server

by iamredmh

@voltanotes/mcp

npm version License: MIT

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:

  1. User creates a note at voltanotes.com and sends the one-time URL

  2. Agent calls read_volta_note — secret returned, note permanently destroyed

  3. Nothing 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/mcp

Step 2 — Register the server:

claude mcp add -s user volta -- node $(npm root -g)/@voltanotes/mcp/dist/index.js

That's it. Restart Claude Code and the create_volta_note and read_volta_note tools will be available.

Why claude mcp add instead 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 user flag makes it available across all projects.

node not found? Use the full path: replace node with the output of which 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

content

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

url

string

Full Volta URL including # fragment

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 fragments

  • The 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 forever

Troubleshooting

Check if the server is connected

claude mcp list

You should see volta: ... ✓ Connected. If not, see below.

Server not showing up

  1. Did you use claude mcp add? Editing ~/.claude/mcp.json manually won't work — Claude Code reads servers from its own registry. Always use claude mcp add to register servers.

  2. Is node on your PATH? Claude Code's shell has a minimal PATH. If node isn't found, use the full path:

    claude mcp add -s user volta -- $(which node) $(npm root -g)/@voltanotes/mcp/dist/index.js
  3. Restart 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 tools
create_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesThe secret content to encrypt and store. Maximum 2,048 characters. Will be AES-256-GCM encrypted before leaving this machine.

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe full Volta note URL including the #fragment key, e.g. https://app.voltanotes.com/r/abc12345#encryptionKeyHere

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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

A4.5/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Self-hosted, zero-knowledge encrypted, self-destructing secrets for secure agent-to-agent coordination
    3
    AGPL 3.0
  • 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.
    1
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables sharing and reading encrypted files (text, images, logs) for AI workflows, with automatic 24-hour expiration and host-blind security.
    35
    156
    MIT

Latest Blog Posts

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