MCP サーバー開発入門：プロトコル仕様と実装例

MCP（Model Context Protocol）は、AI アシスタントに外部のツールやデータをつなぐための共通規格です。Anthropic が 2024 年 11 月に公開し、いまでは OpenAI・Google・Microsoft も対応する事実上の標準になりました。本稿は「MCP とは何か」から、実際に動くサーバーの書き方、通信方式の選び方、認可とセキュリティまでを、はじめての人が読んでも分かるように図とともに整理します。

FIG.1　MCP は「1 度サーバーを作れば、対応するどのクライアントからも使える」共通の差込口

01MCP は「AI 用の USB-C」

MCP が登場する前は、AI に外部ツールをつなぐ方法がベンダーごとにバラバラでした。あるモデルの Function Calling 用に書いた連携コードは、別のモデルでは作り直し。ツール × クライアントの数だけ実装が増える、というのが悩みでした。

MCP は、その差込口を1 つの規格に統一します。USB-C ケーブルが 1 本あればノート PC でもスマホでも充電できるのと同じで、MCP サーバーを 1 度作れば、対応するどのクライアント（Claude、ChatGPT、各種 IDE など）からでも同じように呼び出せます。仕様の中身は JSON-RPC 2.0 でやり取りする、軽量なメッセージ規約です。

作るのはツールごとに 1 回。使えるのは 対応クライアントすべて。これが MCP の効きどころ。

02サーバーが提供できる 3 つの機能

MCP サーバーがクライアントに差し出せる「機能」は、大きく 3 種類です。役割がはっきり分かれているので、最初にここを押さえると設計が楽になります。

迷いやすいのは Tools と Resources の境目です。「AI が能動的に呼んで何かをする」のが Tools、「文脈として読むだけ」のが Resources、と覚えると区別できます。実際の現場では Tools が主役で、Resources・Prompts は補助的に使われることが多いです。

03最小のサーバーを書く（TypeScript）

公式 SDK @modelcontextprotocol/sdk を使うと、サーバー本体は数十行で書けます。現在の推奨は、高レベル API の McpServer クラスと registerTool メソッドです。引数の検証には zod でスキーマを書くのが定番で、入力チェックを SDK 側に任せられます。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "weather-server", version: "1.0.0" });

// ツールを 1 つ登録する（名前・メタ情報・ハンドラ）
server.registerTool(
  "get_weather",
  {
    description: "指定した都市の天気を取得する",
    inputSchema: { city: z.string().describe("都市名") },
  },
  async ({ city }) => {
    const weather = await fetchWeather(city); // 自前の処理
    return { content: [{ type: "text", text: weather }] };
  },
);

// stdio（標準入出力）でクライアントとつなぐ
const transport = new StdioServerTransport();
await server.connect(transport);

古い記事や 2024 年のサンプルでは、低レベルの Server クラスに setRequestHandler("tools/list", …) のように文字列で各ハンドラを登録する書き方が見られます。いまでも動きますが、新規に書くなら McpServer + registerTool のほうが短く、スキーマ検証や一覧応答を自動で面倒みてくれます。

04同じものを Python でも

Python SDK でも考え方は同じで、デコレータでツールを登録します。FastMCP という高レベル API を使うと、関数に印を付けるだけでツールになります。

from mcp.server.fastmcp import FastMCP

server = FastMCP("weather-server")

@server.tool()
def get_weather(city: str) -> str:
    """指定した都市の天気を取得する"""
    return fetch_weather(city)  # 自前の処理

if __name__ == "__main__":
    server.run()  # 既定では stdio で待ち受ける

型ヒント（city: str）と docstring が、そのまま入力スキーマとツール説明として使われます。TypeScript でも Python でも、「関数を 1 つ書いて登録するだけ」という体験は共通です。

05クライアントに登録する

作ったサーバーは、クライアント側の設定ファイルに「どう起動するか」を書いて読み込ませます。Claude Desktop のローカル設定なら、起動コマンドと引数を書くだけです。

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["/path/to/weather-server/index.js"]
    }
  }
}

クライアントを再起動すると、登録したサーバーのツールが AI から見えるようになります。最近の多くのクライアントは、サーバーの一覧から選んでワンクリックで追加できる UI も備えています。

06通信方式：ローカルとリモート

クライアントとサーバーのつなぎ方（トランスポート）は 2 系統あります。ここは2025 年に仕様が大きく変わったところなので、古い情報に注意が必要です。

FIG.2　手元で動かすなら stdio、ネットワーク越しなら Streamable HTTP（単一エンドポイント）

stdio（ローカル）	Streamable HTTP（リモート）
クライアントが子プロセスとして起動	独立したサーバープロセスに HTTP で接続
標準入出力でメッセージをやり取り	単一のエンドポイントに POST / GET
自分の PC 内で完結。設定が簡単	複数ユーザーに提供可。クラウドにデプロイ可

旧仕様には、/sse と /messages の 2 つのエンドポイントを使う HTTP+SSE トランスポートがありました。これは 2025 年 3 月の仕様改訂で非推奨（deprecated）になり、後継として Streamable HTTP（1 つのエンドポイントで、必要なときだけ SSE で逐次レスポンスを流す方式）が標準になっています。古い接続を支えるため両方を併設することはできますが、新規はすべて Streamable HTTP で作るのが現在の指針です。リモート用途では Cloudflare Workers などにデプロイする例が増えています。

07認可とセキュリティ：一番こわいところ

サーバーを社外やネットワークに公開する瞬間から、セキュリティが最重要になります。MCP は 2025 年 6 月の改訂で、HTTP 系トランスポートの認証を OAuth 2.1 で行うことを正式に定めました。位置づけとしては、MCP サーバー＝ OAuth の「保護されたリソース（Resource Server）」です。

FIG.3　トークンの宛先（audience）が自分宛か必ず検証し、他リソース用のトークンは通さない

実装で外せない原則は次のとおりです。

• トークンの宛先（audience）を検証する：自分のサーバー向けに発行されたトークンだけを受け入れ、他の API 用に発行されたトークンは受理も「素通し転送」もしない。
• すべての入力を検証する：ツール引数はスキーマで型を縛り、信頼しない外部入力として扱う。
• 権限チェックは入口だけでなく各ツール呼び出しごとに：「見えてはいけないデータが見える」事故は、ツール単位で境界を引いていないと起こる。
• 機密ファイルへのアクセスを制限：filesystem 系サーバーなら許可ディレクトリを環境変数などで限定する。

もう一つ、MCP 特有の脅威が「ツール・ポイズニング」です。これは、ツールの説明文やメタデータにAI への隠し命令を仕込む攻撃で、モデルがそれを正規の指示と誤解してしまいます。第三者が公開している MCP サーバーを使うときは、コードとツール説明を必ず自分の目で確認し、npm / PyPI 経由の悪意あるパッケージ（サプライチェーン攻撃）にも警戒してください。重要操作は最小権限・要承認を原則に。

08よく使われる公式・コミュニティのサーバー

ゼロから書かなくても、よくある連携はすでに公開されています。代表的なものを挙げます（仕様や名称は更新されることがあるため、最新は公式リポジトリで確認を）。

• filesystem：ローカルファイルの読み書き（許可ディレクトリを限定）
• git / github：リポジトリ操作、Issue・PR の参照や作成
• postgres / sqlite：SQL の実行とスキーマ参照
• memory：会話をまたいだ簡易的な知識の保存
• fetch：URL の取得と本文の抽出
• sequential-thinking：段階的な思考プロセスの支援

サーバーを探す場で言うと、Smithery や Glama といったマーケットプレイスが育ってきており、用途から MCP サーバーを見つけて導入しやすくなっています。導入前にコードを確認する習慣は、ここでも有効です。

092026 年時点の広がり

MCP は「将来そうなるかも」ではなく、すでに業界標準として定着しています。主な動きを時系列で見ると次のとおりです。

これから期待される方向としては、認可・ストリーミング応答のさらなる標準化や、エージェントが必要な MCP サーバーを動的に発見してつなぐ仕組みの成熟が挙げられます（このあたりは進行中で、具体仕様は今後の更新を要確認）。

10まとめ

MCP は、エージェント時代の「USB-C」です。Tools・Resources・Prompts という 3 つの機能を、100 行前後の TypeScript / Python で実装でき、対応クライアントから即座に使えます。新規開発では McpServer / FastMCP の高レベル API を使い、リモート提供なら Streamable HTTP、公開するなら OAuth 2.1 でトークンの宛先を検証し、ツール・ポイズニングに備える——この 3 点を押さえれば、社内ツールと AI をつなぐ実用的なサーバーを安全に作れます。まずは手元で stdio の最小サーバーを 1 つ動かすところから始めましょう。