volta-mcp-server
@voltanotes/mcp
Volta Notes 的 MCP 服务器 —— 可从任何 AI 智能体创建和读取阅后即焚的加密笔记。
笔记使用 AES-256-GCM 进行端到端加密。解密密钥仅存在于 URL 片段中,绝不会发送到任何服务器。笔记存储在 Internet Computer 上,并在读取一次后永久销毁。
为什么使用它
AI 智能体在运行时经常需要敏感信息,如 API 密钥、密码和凭据。目前,用户将这些信息粘贴到聊天中,它们会被永久存储在对话历史记录里。
使用此 MCP 服务器,流程变为:
用户在 voltanotes.com 创建笔记并发送一次性 URL
智能体调用
read_volta_note—— 返回机密信息,笔记被永久销毁聊天记录中不会出现任何敏感信息
反之亦然 —— 智能体可以使用 create_volta_note 通过自毁链接将凭据发送给用户。
Related MCP server: Vaulted MCP Server
快速开始
Claude Code (CLI 和桌面应用)
第 1 步 — 全局安装:
npm install -g @voltanotes/mcp第 2 步 — 注册服务器:
claude mcp add -s user volta -- node $(npm root -g)/@voltanotes/mcp/dist/index.js完成。重启 Claude Code 后,create_volta_note 和 read_volta_note 工具即可使用。
为什么要用
claude mcp add而不是编辑配置文件? Claude Code 从其自身的注册表中读取 MCP 服务器,而不是从~/.claude/mcp.json读取。使用 CLI 可确保服务器正确注册。-s user标志使其在所有项目中均可用。
找不到
node? 请使用完整路径:将node替换为which node的输出(例如/usr/local/bin/node)。
Claude Desktop (独立版)
添加到你的 claude_desktop_config.json 中:
{
"mcpServers": {
"volta": {
"command": "npx",
"args": ["-y", "@voltanotes/mcp"]
}
}
}其他兼容 MCP 的客户端
上述 npx 配置适用于任何支持标准 command/args MCP 格式的客户端 —— 包括 Cursor、Windsurf、Cline、Continue.dev 等。请查看你所用客户端的 MCP 文档,了解在哪里添加服务器配置。
Hermes Agent (Nous Research)
Volta MCP 通过其 MCP 集成与 Hermes Agent 配合使用。将服务器添加到你的 Hermes 配置 (~/.hermes/config.yaml) 中:
mcp:
servers:
- name: volta
command: npx
args:
- "-y"
- "@voltanotes/mcp"重启 Hermes,create_volta_note 和 read_volta_note 工具即可供你的智能体使用。
智能体间的使用场景: 自主运行的 Hermes 智能体通常需要在工作流之间传递凭据,且不能将其暴露在日志或内存中。Volta Notes 专为此设计 —— 一个智能体创建笔记,将一次性 URL 传递给下一个,机密信息在读取时即被销毁。对话历史记录或工具输出日志中不会保留任何内容。
有关完整配置选项,请参阅 Hermes MCP 文档。
Windows (Claude Code CLI)
$(npm root -g) 语法在 PowerShell 或 CMD 中无效。请改用以下方式:
claude mcp add -s user volta -- node "%APPDATA%\npm\node_modules\@voltanotes\mcp\dist\index.js"或者使用上述 Claude Desktop / npx 方法,该方法跨平台通用。
工具
create_volta_note
创建一个加密笔记并返回一个一次性 URL。
参数 | 类型 | 描述 |
| string | 要加密的机密内容(最大 2 KB) |
返回: 一个 voltanotes.com URL。接收者打开一次,读取内容后,它将永远消失。
read_volta_note
读取并永久销毁一个 Volta 笔记。
参数 | 类型 | 描述 |
| string | 包含 |
返回: 解密后的笔记内容。笔记将从 canister 中永久删除 —— 第二次读取将失败。
智能体提示词片段
将此内容添加到任何智能体的系统提示词中,以启用安全凭据传递:
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.安全模型
AES-256-GCM 加密在发送到 canister 之前在本地完成
加密密钥仅存在于 URL 片段 (
#...) 中 —— 浏览器和服务器从不传输片段ICP canister 仅存储密文 —— 即使被攻破,所有数据也无法读取
笔记在首次读取时销毁。未读笔记将在 7 天后过期。
无账户、无登录、无追踪
工作原理
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故障排除
检查服务器是否已连接
claude mcp list你应该看到 volta: ... ✓ Connected。如果没有,请参阅下文。
服务器未显示
你是否使用了
claude mcp add? 手动编辑~/.claude/mcp.json是无效的 —— Claude Code 从其自身的注册表中读取服务器。请始终使用claude mcp add来注册服务器。node是否在你的 PATH 中? Claude Code 的 shell 具有最小化的 PATH。如果找不到node,请使用完整路径:claude mcp add -s user volta -- $(which node) $(npm root -g)/@voltanotes/mcp/dist/index.js需要重启。 添加或更改 MCP 服务器后,请完全重启 Claude Code(退出并重新打开)。
如何知道服务器是否已启动?
服务器在成功启动时会将 Volta MCP server started 记录到 stderr。运行 claude mcp list 以检查连接状态。
要求
Node.js 18+ (使用内置的 Web Crypto API)
许可证
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