Skip to main content
Glama
deenesjakoruzh
iamredmh

volta-mcp-server

by iamredmh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

@voltanotes/mcp

npm version License: MIT

Volta Notes 用のMCPサーバー — AIエージェントから一度読み取ると消滅する暗号化ノートを作成・読み取りします。

ノートはAES-256-GCMを使用してエンドツーエンドで暗号化されます。復号キーはURLフラグメント内にのみ存在し、サーバーに送信されることはありません。ノートはInternet Computerに保存され、一度読み取られると完全に破棄されます。

目的

AIエージェントは実行時にAPIキー、パスワード、認証情報などの機密情報を必要とすることがよくあります。現在、ユーザーはこれらをチャットに貼り付けており、会話履歴に永続的に保存されてしまいます。

このMCPサーバーを使用すると、以下のパターンが可能になります：

  1. ユーザーがvoltanotes.comでノートを作成し、ワンタイムURLを送信する

  2. エージェントが read_volta_note を呼び出す — シークレットが返され、ノートは完全に破棄される

  3. チャット履歴に機密情報が一切残らない

またはその逆として、エージェントが 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は ~/.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 設定は、標準の 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を返します。

パラメータ

型

説明

content

string

暗号化するシークレットコンテンツ（最大2 KB）

戻り値: voltanotes.com URL。受信者が一度開いて内容を読み取ると、二度とアクセスできなくなります。

read_volta_note

Voltaノートを読み取り、完全に破棄します。

パラメータ

型

説明

url

string

# フラグメントを含む完全なVolta URL

戻り値: 復号されたノートの内容。ノートはキャニスターから完全に削除されるため、二度目の読み取りは失敗します。

エージェントプロンプトの例

安全な認証情報の受け渡しを有効にするために、エージェントのシステムプロンプトに以下を追加してください：

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 list

volta: ... ✓ Connected と表示されるはずです。表示されない場合は以下を確認してください。

サーバーが表示されない場合

  1. claude mcp add を使用しましたか？ ~/.claude/mcp.json を手動で編集しても機能しません。Claude Codeは独自のレジストリからサーバーを読み取ります。サーバーの登録には必ず claude mcp add を使用してください。

  2. node はPATHに含まれていますか？ Claude Codeのシェルは最小限のPATHしか持ちません。 node が見つからない場合は、フルパスを使用してください：

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

  3. 再起動が必要です。 MCPサーバーを追加または変更した後は、Claude Codeを完全に再起動（終了して再起動）してください。

サーバーが起動したかどうかを確認する方法

サーバーは起動に成功すると、stderrに Volta MCP server started とログを出力します。 claude mcp list を実行して接続状態を確認してください。

要件

  • Node.js 18+ (組み込みのWeb Crypto APIを使用)

ライセンス

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedcreate_volta_note
    • First observedread_volta_note
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored across 2 tools

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
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • zKettle

    benderterminal
    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

  • SecureNote.link MCP Server

    jackalterman
    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
    -

  • vnsh-mcp

    raullenchai
    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.
    19 npm
    157
    MIT