EVM MCPを試してみた

こんにちは。次世代システム研究室のL.W.です。

イーサリアムを始めのブロックチェーンは、革新的で優れた機能を持っていますが、社会的な応用にはまだ課題が残っています。

ウォレットの管理・運用が難しい（「Metamaskって何？」）、ブロックチェーン上のデータを読み取りにくい（L1やL2それぞれのブロックチェーン・エクスプローラーって？）、スマートコントラクトが理解しにくい（公平性を担保する仕組みである一方、技術格差が生じる）など、多くの障壁がマスアダプションの前に立ちはだかっています。

AIが強い時代ですが、果たしてAIはブロックチェーンに新しい風を吹き込むことができるのでしょうか。

今回は「AI × Blockchain」をテーマの一つとして、EVM系ブロックチェーンとやり取りできるMCPを検証してみました。ぜひ皆さんと共有したいと思います。

1.MCPの仕組み

1.3. MCP Server

1.4. 基本的な仕組み

1. MCP Hostが起動すると、指定された MCP サーバーの定義（JSONファイルまたはコネクタ）を読み込みます。

2. その定義に基づき、MCP Hostは MCP Clientを生成します。

3. それぞれのMCP clientは対応するMCP serverと接続し、機能（Local Data SourceまたはRemote Service）を MCP Hostを通してLLMに提供します。

Foundryの仕組み

3.EVM MCPを検証する

データベース（DB）に関わるMCPですが、genai-toolbox はよく知られて、よく検証されているんでしょう。

MCP Toolbox for Databases を使うことで、こうした低レベルの処理を自分で実装する必要がなくなり、ツール開発をより簡単・高速・安全 に進められます。

MCP Toolbox for Databases = データベース連携のための「便利な共通部品セット」と認識しても良いでしょう。

一方、ブロックチェーンと連携のための「便利な共通部品セット」がありますか。

Foundry MCP ServerというMCPを見つけたので、検証してみました。

イーサリアムだけではなく、EVM系にサポートされていますので、僕は勝手にEVM MCPに呼びます。（笑）

３.1. 構成

今回の検証でClaude Desktopを使いました。LLMはSonnet 4に指定しました。

blockchain providerはAlchemyにしました。イーサリアムのテストネットのSepoliaを利用しました。ローカルにnodejs、foundryのルールチェーンをインスタールしておく必要があります。

３.2. 検証

OSSのfoundry-mcp-serverを活用しました。

claude_desktop_config.jsonファイルを以下のように設定しました。

{
  "mcpServers": {
    "foundry": {
      "command": "node",
      "args": ["/foundry-mcp-server/dist/index.js"],
      "env": {
        "RPC_URL": "https://eth-sepolia.g.alchemy.com/v2/<your key>",
        "PRIVATE_KEY": "0x<your from address key>"
      }
    }
  }
}

３.２.１ ETHの送金

ソースではETHの送金機能が上手くいかないので、コードを以下の方に追加して、送金を実現できました。

import { z } from "zod";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { checkFoundryInstalled, executeCommand, FOUNDRY_PATHS, FOUNDRY_NOT_INSTALLED_ERROR } from "../../utils/command.js";
import { resolveRpcUrl } from "../../utils/rpc.js";
import * as dotenv from "dotenv"
dotenv.config();

//// transfer ETH to an address
// cast send 0xE6b48d76Bc4805ABF61F38A55F1D7C362c8BfdA8 --value 100000000000000000 --private-key 0x123... --rpc-url "https://eth-sepolia.g.alchemy.com/v2/key"

export function registerCastTransferTool(server: McpServer): void {
  server.tool(
    "cast_transfer",
    "Transfer ETH to an address",
    {
      to: z.string().describe("Recipient address"),
      value: z.string().describe("Amount of ETH to send (in wei)"),
      rpcUrl: z.string().optional().describe("JSON-RPC URL (default: http://localhost:8545)"),
    },
    async ({ to, value, rpcUrl }) => {
      const installed = await checkFoundryInstalled();
      if (!installed) {
        return {
          content: [{ type: "text", text: FOUNDRY_NOT_INSTALLED_ERROR }],
          isError: true
        };
      }

      const resolvedRpcUrl = await resolveRpcUrl(rpcUrl);
      const privateKey = process.env.PRIVATE_KEY;
      let command = `${FOUNDRY_PATHS.castPath} send ${to} --value ${value} --private-key ${privateKey} --rpc-url "${resolvedRpcUrl}"`;

      const result = await executeCommand(command);

      return {
        content: [{
          type: "text",
          text: result.success
            ? `Transaction sent successfully:\n${result.message}`
            : `Transaction failed: ${result.message}`
        }],
        isError: !result.success
      };
    }
  );
}

詳しくは以下に参照できます。結果はここです。

３.２.2 コントラクト分析と解説

３.２.3 token送金

結果はここです。

３.２.4 コントラクトの作成とデプロイ

結果はここです。

３.２.5 コントラクトとやり取り

結果はここです。

３.２.6 トランザクションを解説

３.２.7 コントラクトの可読性を高める

３.3. 注意

まだ実験段階なので、本番での試しは控え目にしたほうがいいでしょう。

今回の検証では、MCPは時には想定外のことをしたことがありました。

4.まとめ

ウォレットが分からなくても資金を管理でき、ブロックチェーンエクスプローラーを見なくてもデータを理解でき、さらにSolidityなどのプログラミング言語を知らなくても複雑なスマートコントラクトを理解できるようになる――。自然言語でブロックチェーン、web3に安易に触れるようになります。

この「EVM MCP」はまだ不十分な部分もありますが、ブロックチェーンが抱える課題をある程度解決できる可能性が秘めています。

不十分な点としてまず挙げられるのは、プライベートキーの管理です。流出や盗難のリスクが常に存在しており、決定的な解決方法はいまだに見つかっていません。どのアカウントにどのような権限を付与すれば良いかについてもまだ議論中でしょう。

各クレジットカード会社もクレカMCPもこれから世に出せますが、権限といった「信頼のレイヤー」も研究の進行中に見れますね。アカウントへの権限、クレカへの権限、両者は共通部分があるかと認識しています。

次に、DeFiアプリとのやり取りについてです。foundryのtoolchainだけでは対応できず、各DeFiのAPIをEVM MCPに取り込んでいく必要があります。しかし、開発が広がる一方で、セキュリティ面での問題も発生しやすくなります。

また、リスクの原因がLLM側の欠陥か、DeFi API側の欠陥かにかかわらず、資金損失に繋がる可能性は常に存在しています。

これからのLLMやMCPの発展を引き続き見守っていきたいと思います。一緒に楽しみにしましょう。

5.最後に

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。

皆さんのご応募をお待ちしています。