AI News HubLIVE
サイト内リライト3 分で読了

ステートレスMCPが再び興味を呼び起こした(mcp-explorer と datasette-mcp のきっかけに)

ステートレスなMCP 2.0(2026-07-28仕様)により、クライアントとサーバーの実装が大幅に簡素化された。Simon Willison氏はこれを使ってmcp-explorer、datasette-mcp、llm-mcp-clientの3つのツールを開発し、汎用エージェントにシェルやcurlへの自由なアクセスを与えるよりもMCPの方が監査・制御が容易で安全だと述べている。

ステートレスMCPが再び興味を呼び起こした(mcp-explorer と datasette-mcp のきっかけに)

7月28日に公開されたModel Context Protocol 2.0仕様、通称「ステートレスMCP」は、MCPが登場して以来最も大きな変更であり、著者であるSimon Willison氏の関心を再びこのプロトコルに向けさせた。

MCPはAnthropicが2024年11月に発表したプロトコルで、LLMを搭載したエージェントフレームワークにツールを公開する標準的な方法を定めるものだ。2025年を通して大きな関心を集めたが、ターミナルとcurlにアクセスできるエージェントハーネスがあれば、MCPでできることのほとんどをより柔軟な方法で実現できることが明らかになり、同じくAnthropicが開発したSkillsに注目が移っていた。しかしWillison氏は今、MCPに回帰しつつある。エージェントにインターネットへアクセスできるシェル環境を与えるのはリスクが高く、その環境を効果的に操作できる強力なモデルが必要だ。MCPのツールは監査・制御が容易で、ラップトップで動く小さなモデルでも十分に扱えるほどシンプルだ。新しいステートレスMCP仕様は、クライアントとサーバーの両方の実装複雑性も大幅に下げている。

旧来のステートフルなMCP(Willison氏は「レガシーMCP」と呼ぶ)では、セッションを初期化してMcp-Session-Idを取得するためのHTTPリクエストと、ツールを呼び出すためのHTTPリクエストの2回が必要だった。新しいステートレス方式では、MCP-Protocol-Version、Mcp-Method、Mcp-Nameをヘッダーに含めた1回のHTTPリクエストで済む。これはクライアント側・サーバー側の両方の実装をよりクリーンにし、セッションIDをサーバー側で管理したり、同じセッションを同じバックエンドマシンにルーティングしたりする必要がないため、スケーラブルなWebアプリケーションにも適している。

Willison氏は今週、この新仕様に基づいて3つのツールを開発した。1つ目はmcp-explorer。MCPサーバーを対話的に調査するCLIツールで、Python製のステートレスなツールのため、uvxを使えばインストールなしで試せる。Ade Oshineye氏のagentic-mermaid.devデモMCPサーバーに対してツール一覧の取得や、ツールの入出力JSONスキーマの表示、引数を渡してのツール呼び出しなどができる。

2つ目はdatasette-mcp。Datasetteインスタンスに/-/mcpエンドポイントを追加するプラグインだ。提供するツールはlist_databases()、get_database_schema(database_name)、execute_sql(database_name, sql)の3つだけで、execute_sql()は当面読み取り専用となっている。ChatGPTやClaudeなどのエージェントに接続すれば、ホストされているDatasetteインスタンスに対してSQLクエリを実行できるようになる。実際にWillison氏のブログのDatasetteミラーで稼働しており、Claudeが7つのSQLクエリを実行して「Simonが最近MCPについて何を言ったか」という質問に答えた共有セッションも公開されている。

3つ目はllm-mcp-client。Willison氏のLLMツールにMCP統合をもたらすアルファ版プラグインだ。インストール後、llm -T 'MCP("https://datasette.simonwillison.net/-/mcp")' 'count the notes'のようなコマンドで、MCPを介してモデルにデータを問い合わせられる。完成度が高まればLLMコアに直接組み込む予定で、Datasette Agentやllm-coding-agentでもMCPを試したいと考えている。

セキュリティについて、Willison氏はMCP公開直後に「Model Context Protocol has prompt injection security problems」という記事を書き、エンドユーザーがツールを自由に組み合わせるパターンは、データ外部送信攻撃を防ぐ責任を利用者側に押し付けるものだと指摘していた。その後、任意のシェルやcurlにアクセスできる汎用エージェントが登場し、セキュリティ確保はさらに難しくなった。MCPは、オープンなネットワーク環境での任意コマンド実行と比べ、エージェントの能力や何が問題になり得るかをはるかに推論しやすい。LLM上に機密性の高いアプリケーションを構築する際には、今後MCPを積極的に活用していく考えだ。