volta-mcp-server
@voltanotes/mcp
MCP-Server für Volta Notes — Erstellen und Lesen von „Burn-after-read“-verschlüsselten Notizen durch jeden beliebigen KI-Agenten.
Notizen sind mittels AES-256-GCM Ende-zu-Ende-verschlüsselt. Der Entschlüsselungsschlüssel befindet sich ausschließlich im URL-Fragment — er wird niemals an einen Server gesendet. Notizen werden auf dem Internet Computer gespeichert und nach dem ersten Lesen dauerhaft gelöscht.
Warum
KI-Agenten benötigen zur Laufzeit regelmäßig sensible Informationen — API-Schlüssel, Passwörter, Anmeldedaten. Heutzutage fügen Benutzer diese in Chats ein, wo sie dauerhaft im Gesprächsverlauf gespeichert bleiben.
Mit diesem MCP-Server ändert sich das Muster wie folgt:
Der Benutzer erstellt eine Notiz unter voltanotes.com und sendet die Einmal-URL.
Der Agent ruft
read_volta_noteauf — das Geheimnis wird zurückgegeben, die Notiz wird dauerhaft gelöscht.Nichts Sensibles erscheint jemals im Chatverlauf.
Oder umgekehrt — ein Agent kann create_volta_note verwenden, um Anmeldedaten über einen selbstzerstörenden Link an einen Benutzer zu senden.
Related MCP server: Vaulted MCP Server
Schnellstart
Claude Code (CLI & Desktop-App)
Schritt 1 — Global installieren:
npm install -g @voltanotes/mcpSchritt 2 — Server registrieren:
claude mcp add -s user volta -- node $(npm root -g)/@voltanotes/mcp/dist/index.jsDas war's. Starten Sie Claude Code neu, und die Tools create_volta_note und read_volta_note stehen zur Verfügung.
Warum
claude mcp addanstatt Konfigurationsdateien zu bearbeiten? Claude Code liest MCP-Server aus seiner eigenen Registrierung, nicht aus~/.claude/mcp.json. Die Verwendung der CLI stellt sicher, dass der Server korrekt registriert wird. Das Flag-s usermacht ihn für alle Projekte verfügbar.
nodenicht gefunden? Verwenden Sie den vollständigen Pfad: Ersetzen Sienodedurch die Ausgabe vonwhich node(z. B./usr/local/bin/node).
Claude Desktop (Standalone)
Fügen Sie dies zu Ihrer claude_desktop_config.json hinzu:
{
"mcpServers": {
"volta": {
"command": "npx",
"args": ["-y", "@voltanotes/mcp"]
}
}
}Andere MCP-kompatible Clients
Die obige npx-Konfiguration funktioniert mit jedem Client, der das Standard-MCP-Format command/args unterstützt — einschließlich Cursor, Windsurf, Cline, Continue.dev und anderen. Überprüfen Sie die MCP-Dokumentation Ihres Clients, wo die Serverkonfiguration hinzugefügt werden muss.
Hermes Agent (Nous Research)
Volta MCP funktioniert mit dem Hermes Agent über dessen MCP-Integration. Fügen Sie den Server zu Ihrer Hermes-Konfiguration (~/.hermes/config.yaml) hinzu:
mcp:
servers:
- name: volta
command: npx
args:
- "-y"
- "@voltanotes/mcp"Starten Sie Hermes neu, und die Tools create_volta_note und read_volta_note stehen Ihrem Agenten zur Verfügung.
Agent-zu-Agent-Anwendungsfall: Autonom laufende Hermes-Agenten müssen häufig Anmeldedaten zwischen Workflows weitergeben, ohne diese in Protokollen oder im Arbeitsspeicher offenzulegen. Volta Notes wurde genau dafür entwickelt — ein Agent erstellt eine Notiz, gibt die Einmal-URL an den nächsten weiter, und das Geheimnis wird beim Lesen zerstört. Nichts bleibt im Gesprächsverlauf oder in den Tool-Ausgabeprotokollen bestehen.
Siehe die Hermes MCP-Dokumentation für vollständige Konfigurationsoptionen.
Windows (Claude Code CLI)
Die Syntax $(npm root -g) funktioniert nicht in PowerShell oder CMD. Verwenden Sie stattdessen dies:
claude mcp add -s user volta -- node "%APPDATA%\npm\node_modules\@voltanotes\mcp\dist\index.js"Oder verwenden Sie die oben genannte Claude Desktop / npx-Methode, die plattformübergreifend funktioniert.
Tools
create_volta_note
Erstellt eine verschlüsselte Notiz und gibt eine Einmal-URL zurück.
Parameter | Typ | Beschreibung |
| string | Zu verschlüsselnder geheimer Inhalt (max. 2 KB) |
Rückgabe: Eine voltanotes.com-URL. Der Empfänger öffnet sie einmal, liest den Inhalt, und er ist für immer verschwunden.
read_volta_note
Liest und zerstört eine Volta-Notiz dauerhaft.
Parameter | Typ | Beschreibung |
| string | Vollständige Volta-URL inklusive |
Rückgabe: Der entschlüsselte Notizinhalt. Die Notiz wird dauerhaft aus dem Kanister gelöscht — ein zweiter Leseversuch schlägt fehl.
Agent-Prompt-Snippet
Fügen Sie dies zum System-Prompt eines jeden Agenten hinzu, um eine sichere Übergabe von Anmeldedaten zu ermöglichen:
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.Sicherheitsmodell
AES-256-GCM-Verschlüsselung erfolgt lokal, bevor Daten an den Kanister gesendet werden.
Der Verschlüsselungsschlüssel existiert nur im URL-Fragment (
#...) — Browser und Server übertragen niemals Fragmente.Der ICP-Kanister speichert nur den Geheimtext — selbst bei einer Kompromittierung sind alle Daten unlesbar.
Notizen werden beim ersten Lesen zerstört. Ungelesene Notizen verfallen nach 7 Tagen.
Keine Konten, kein Login, kein Tracking.
Funktionsweise
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 foreverFehlerbehebung
Überprüfen, ob der Server verbunden ist
claude mcp listSie sollten volta: ... ✓ Connected sehen. Falls nicht, siehe unten.
Server wird nicht angezeigt
Haben Sie
claude mcp addverwendet? Das manuelle Bearbeiten von~/.claude/mcp.jsonfunktioniert nicht — Claude Code liest Server aus seiner eigenen Registrierung. Verwenden Sie immerclaude mcp add, um Server zu registrieren.Ist
nodein Ihrem PATH? Die Shell von Claude Code hat einen minimalen PATH. Wennnodenicht gefunden wird, verwenden Sie den vollständigen Pfad:
claude mcp add -s user volta -- $(which node) $(npm root -g)/@voltanotes/mcp/dist/index.jsNeustart erforderlich. Nach dem Hinzufügen oder Ändern eines MCP-Servers starten Sie Claude Code vollständig neu (beenden und erneut öffnen).
Woher weiß ich, ob der Server gestartet wurde?
Der Server protokolliert bei erfolgreichem Start Volta MCP server started in stderr. Führen Sie claude mcp list aus, um den Verbindungsstatus zu überprüfen.
Anforderungen
Node.js 18+ (verwendet die integrierte Web Crypto API)
Lizenz
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.0.0- First observed
create_volta_note - First observed
read_volta_note
TDQS
Scored across 2 tools
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
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.
Meet an agent you have not met, exchange messages that expire, and prove it happened. No account.
Deploy HTML and Markdown as live URLs. Create, search, update, and manage pastes from any AI agent.
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.414 npm1MIT
- 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.19 npm157MIT