MCPサーバーアーキテクチャ（エムシーピーサーバーアーキテクチャ）

MCPサーバーアーキテクチャは、LLMアプリケーション（ホスト）に対してツール・リソース・プロンプトを公開するサーバー側の設計構造である。MCPサーバーはステートフルな接続を維持し、JSON-RPC 2.0プロトコルでクライアントと双方向通信を行う。サーバーの実装方式はstdio（標準入出力）、SSE（Server-Sent Events）、Streamable HTTPの3種類があり、ユースケースに応じて選択する。

サーバーのライフサイクル

MCPサーバーは以下のライフサイクルで動作する。

1. 初期化フェーズ: クライアントがinitializeリクエストを送信し、プロトコルバージョンとCapabilityを交換する。サーバーは自身がサポートするツール・リソース・プロンプトの一覧を宣言する
2. Capabilityネゴシエーション: クライアントとサーバーが互いの機能セットを確認し、共通のプロトコルバージョンで合意する。不一致の場合は接続が拒否される
3. 運用フェーズ: tools/call、resources/read、prompts/get等のリクエストを処理する。接続はステートフルで、セッション中のコンテキストが保持される
4. 終了フェーズ: クライアントがcloseを呼び出すか、トランスポートが切断されると接続が終了する

TypeScript SDKによるサーバー実装

公式TypeScript SDK（@modelcontextprotocol/sdk）を使った最小構成のサーバー実装例を示す。

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

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

// ツール定義
server.tool("get_weather", { city: { type: "string" } }, async ({ city }) => ({
  content: [{ type: "text", text: `${city}の天気: 晴れ 25°C` }],
}));

// stdioトランスポートで起動
const transport = new StdioServerTransport();
await server.connect(transport);

この最小構成は約15行で完成し、stdioトランスポート経由でClaude DesktopやClaude Codeから呼び出せる。

Python SDKによるサーバー実装

Python版MCP SDK（mcpパッケージ、PyPI公開）ではデコレータベースの簡潔な記法でサーバーを定義できる。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("example-server")

@mcp.tool()
def get_weather(city: str) -> str:
    return f"{city}の天気: 晴れ 25°C"

@mcp.resource("config://app")
def get_config() -> str:
    return "アプリケーション設定データ"

FastMCPクラスはFlask/FastAPIライクなAPIで、Pythonの型ヒントからJSON Schemaを自動生成する。mcp run server.pyコマンドでstdioサーバーとして起動し、mcp dev server.pyで開発用インスペクタUIが利用できる。

SDK比較表

サーバー設計パターン

MCPサーバーの設計には以下のパターンが一般的である。

• 単一責務サーバー: 1つのサービス（GitHub、Slack、PostgreSQL等）に特化したサーバー。依存関係が明確で、テストとデプロイが容易
• 複合サーバー: 関連する複数のツールをまとめたサーバー。DevOpsツール群（Docker + Kubernetes + Terraform）など
• プロキシサーバー: 既存のREST APIやGraphQL APIをMCPプロトコルにブリッジするサーバー。レガシーシステムのMCP対応に有効
• ゲートウェイサーバー: 複数のMCPサーバーを集約し、単一のエンドポイントとしてホストに公開する。認証やレート制限を一元管理する

ホスト側の設定例

Claude Desktopでのclaude_desktop_config.json設定例:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_xxxx" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
    }
  }
}

Claude Codeではプロジェクトルートの.claude/settings.jsonにMCPサーバー設定を記述し、claude mcp addコマンドでインタラクティブに追加することもできる。

よくある質問（FAQ）

Q1: MCPサーバーのデバッグ方法は？ A: MCP Inspectorを使う。npx @modelcontextprotocol/inspectorで起動し、ブラウザベースのUIでツール呼び出しのリクエスト/レスポンスをリアルタイム確認できる。Claude Desktopのログ（~/Library/Logs/Claude/mcp*.log）も有用な情報源である。

Q2: 1つのホストから複数のMCPサーバーに接続できますか？ A: できる。各MCPサーバーとは独立した1:1接続が確立されるため、GitHub用・Slack用・DB用など複数のサーバーを同時に利用できる。Claude Codeではclaude mcp listで接続中のサーバー一覧を確認でき、10以上のサーバーを同時接続する運用事例もある。

Q3: MCPサーバーをDockerコンテナで実行できますか？ A: できる。stdioトランスポートの場合はdocker run -iで標準入出力を接続し、Streamable HTTPの場合はコンテナのポートを公開する。公式リファレンスサーバー（@modelcontextprotocol/server-github等）の多くはDockerfileが同梱されており、docker composeでの運用も想定されている。

まとめ

• MCPサーバーはTools・Resources・Promptsを公開するステートフルなサービス
• TypeScript/Python/Java/Kotlin/C#の公式SDKで15〜30行で実装可能
• 単一責務・複合・プロキシ・ゲートウェイの4パターンで設計
• MCP Inspectorによるデバッグ環境が標準提供
• claude_desktop_config.jsonや.claude/settings.jsonでホスト側設定を管理