volta-mcp-server
@voltanotes/mcp
Volta Notes용 MCP 서버 — 모든 AI 에이전트에서 읽은 후 즉시 삭제되는(burn-after-read) 암호화된 노트를 생성하고 읽을 수 있습니다.
노트는 AES-256-GCM을 사용하여 **종단간 암호화(end-to-end encrypted)**됩니다. 복호화 키는 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/mcp2단계 — 서버 등록:
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는~/.claude/mcp.json이 아닌 자체 레지스트리에서 MCP 서버를 읽어옵니다. 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 설정은 Cursor, Windsurf, Cline, Continue.dev 등을 포함하여 표준 command/args MCP 형식을 지원하는 모든 클라이언트에서 작동합니다. 서버 설정을 추가하는 방법은 각 클라이언트의 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 |
|
반환값: 복호화된 노트 내용. 노트는 캐니스터에서 영구적으로 삭제되므로 두 번째 읽기는 실패합니다.
에이전트 프롬프트 스니펫
안전한 자격 증명 전달을 활성화하려면 에이전트의 시스템 프롬프트에 다음을 추가하세요:
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 암호화는 캐니스터로 전송되기 전 로컬에서 수행됩니다.
암호화 키는 URL 프래그먼트(
#...)에만 존재하며, 브라우저와 서버는 프래그먼트를 전송하지 않습니다.ICP 캐니스터는 암호문만 저장하므로, 침해되더라도 모든 데이터는 읽을 수 없습니다.
노트는 첫 번째 읽기 시 파기됩니다. 읽지 않은 노트는 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 listvolta: ... ✓ Connected가 표시되어야 합니다. 그렇지 않다면 아래를 확인하세요.
서버가 표시되지 않는 경우
claude mcp add를 사용했나요?~/.claude/mcp.json을 수동으로 편집하는 것은 작동하지 않습니다. Claude Code는 자체 레지스트리에서 서버를 읽습니다. 항상claude mcp add를 사용하여 서버를 등록하세요.node가 PATH에 있나요? Claude Code의 셸은 최소한의 PATH를 가집니다.node를 찾을 수 없다면 전체 경로를 사용하세요:claude mcp add -s user volta -- $(which node) $(npm root -g)/@voltanotes/mcp/dist/index.js재시작이 필요합니다. MCP 서버를 추가하거나 변경한 후에는 Claude Code를 완전히 종료했다가 다시 시작하세요.
서버가 시작되었는지 어떻게 알 수 있나요?
서버가 성공적으로 시작되면 stderr에 Volta MCP server started를 기록합니다. 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