MCP Go SDKとは？2025年最新：導入に必要な環境構築と事前準備について徹底解説

MCP Go SDKとは？2025年最新：導入に必要な環境構築と事前準備について徹底解説

MCP Go SDKとは何か: 背景と役割

MCP (Model Context Protocol) は、大規模言語モデル (LLM) が外部のツールやサービスと通信する方法を標準化するオープンプロトコルです。Anthropic社によって策定され、AIアプリケーションに対してUSB-Cのように統一的な接続インターフェースを提供することを目指しています。このプロトコルにより、AIエージェントは自分の持つ知識を超えて外部の情報源にアクセスしたり、外部ツールを呼び出したりすることが可能になります。

MCP Go SDKは、そのMCPをGo言語で利用するためのソフトウェア開発キットです。すなわち、Goで自分専用のMCPサーバー（＝外部ツール群を提供するサービス）やMCPクライアント（＝LLM側の呼び出し手）を実装できるライブラリ群を指します。MCP Go SDKを使うことで、LLMアプリケーションと外部ツールのシームレスな連携が可能になり、開発者はAIに新しい「能力」をプラグインのように教え込むことができます。

MCP Go SDKでできること: 特徴とメリット

MCP Go SDKを利用すると、例えば以下のようなことが実現できます。

• 外部データへのアクセス: LLMがローカルファイルやデータベース、Web APIなどにアクセスするツールを提供できる
• 外部コマンドの実行: シェルコマンドや他のアプリケーションをLLM経由で実行できる（例：システム情報取得やビルドツールの実行）
• 複雑な処理の委譲: LLM単体では難しい複雑な計算や専門処理をGoで実装したツールに委ね、結果を受け取る
• マルチエージェント連携: 複数のAIエージェント同士がMCPを介して連携し、互いに専門能力を提供し合う

要するに、MCP Go SDKはLLMに「工具箱」を与えるイメージです。Go言語で作成されたツール群をMCPサーバーとして用意し、LLM（MCPクライアント）はプロトコルに沿ってそのツール箱から必要な工具を取り出して使います。これによりAIアプリケーションの拡張性が飛躍的に高まり、プログラミング支援やデータ分析など目的に応じて自由に機能を追加できます。

特にGo製のSDKは動作が高速かつ軽量で、大規模な言語モデルとの統合に適しています。MCP-Go（コミュニティ版SDK）の公式ドキュメントによれば、「高速 (オーバーヘッド最小)、シンプル（直感的なAPIでボイラープレート最小）、完全（ツール・リソース・プロンプトなどMCP仕様を全てサポート）」という特徴を備えています。これらのメリットにより、中級レベルの開発者であればMCP Go SDKを使って比較的容易にAIと外部システムの連携アプリを構築できるでしょう。

開発環境の前提条件: OSや依存ツールの要件

MCP Go SDKを利用するためには、まず開発および実行環境の準備が必要です。基本的な前提条件として：

• Go言語開発環境（最新の安定版推奨：少なくともGo 1.20+）
• Node.js 20以上（Gemini CLIを使用する場合に必要。Gemini CLI自体がNode.jsで実装されているため）
• サポートOS: macOS、Linux、Windowsなど主要OSで動作可能
• （オプション）Docker等のコンテナ環境（後述するクラウドデプロイやCloud Run利用時に必要になる場合あり）

上記のうち、GoとNode.jsが特に重要です。GoはMCPサーバー/ツール自体を実装するのに使い、Node.jsはGoogle提供のAIエージェントであるGemini CLIを動かすのに必要です。Gemini CLIはターミナル上で動作するLLMエージェントで、MCP経由で我々のGo製ツールを呼び出すクライアントの役割を果たします。したがって、ローカルPC上でGemini CLIとMCPサーバー（Goアプリ）を連携させて試すには、双方が動作する環境を用意する必要があります。

なお、Google Cloud上で実験する場合は、gcloud CLIやクラウドプロジェクトの設定も必要になるケースがあります。しかし本記事では主にローカル環境で動かす手順を念頭に解説します。

Go開発環境のセットアップ: Go言語や必要ライブラリのインストール

Go言語の開発環境は公式サイトから提供されているインストーラや、各OSのパッケージマネージャー(Homebrewやaptなど)で簡単にインストールできます。インストール後、go versionコマンドで適切なバージョンが入ったことを確認してください。MCP Go SDKを扱うにはモジュール対応版のGo（Go Modules）が必要ですが、Go 1.16以降であればデフォルトでModulesが有効なので特別な設定は不要です。

また、Go環境セットアップの一環としてGOPATHやプロキシの設定が気になるかもしれませんが、現在はモジュールモードのためプロジェクトディレクトリ内でgo mod initさえ適切に行えばGOPATHは意識せずに開発できます。後述するように、まずプロジェクト用のディレクトリを作成してgo mod initを実行し、モジュールを初期化しておきましょう。

次に、MCP Go SDK自体のインストールです。利用するSDKの実装によってインポート先が異なります。代表的な選択肢は以下の2つです。

• コミュニティ版 (mark3labs/mcp-go): Ed Zynda氏が開発したオープンソース実装。GitHubで約6.9kものスターを集めている人気プロジェクトです。インストールは go get github.com/mark3labs/mcp-go のようにgo getで取得できます。
• 公式版 (modelcontextprotocol/go-sdk): Googleと協業して開発されている公式SDK。GitHub上で管理されておりMITライセンスで公開されています。こちらも go get github.com/modelcontextprotocol/go-sdk で導入できます（※執筆時点ではスター数約1.6k）。

どちらのSDKも基本的な機能は共通しており、MCPの標準仕様に沿ったツール・リソース・プロンプトの実装をサポートします。コミュニティ版のノウハウが公式版に取り入れられており、実際公式SDKの設計にはEd Zynda氏のmcp-goが大きく貢献しています。本記事では概念の説明や簡単なコード例にコミュニティ版を用いつつ、適宜公式SDKとの比較にも言及します。

MCPサーバーの作り方：Go言語を用いたローカル環境構築からサーバー起動までをステップバイステップで丁寧に解説

MCPサーバー構築の全体像: サーバーとクライアントの関係

まず、MCPサーバーとは何かを整理しましょう。MCPにおける「サーバー」は、LLMから見て外部ツールを提供する側のプロセスです。つまり、開発者がGoで実装するMCPサーバーは、種々のツール(APIやコマンドなど)を登録し、それをLLM（クライアント）が呼び出せるように待ち受ける役割を担います。一方、MCPクライアント（例えばGemini CLIやその他の対応LLM環境）は、ユーザからの指示に応じて必要なツールをMCPサーバーにJSON-RPC経由で呼び出します。

この関係性は、Webのクライアントサーバーモデルにも少し似ています。クライアント（LLM側）は「こんなツールを使いたい」というリクエストを送り、サーバー（ツール側）はそれを実行して結果を返すという流れです。重要な点は、MCPによってクライアントとサーバー間の通信手順やメッセージ形式が標準化されているため、互いの実装に依存せずにやりとりできることです。クライアントがMCPに対応していれば、どんな言語で作られたサーバーでも接続して使えるという疎結合な設計になっています。

実際の構築手順としては、概ね以下のステップで進めます。

1. プロジェクトの作成と初期化（Goモジュールの設定）
2. MCPサーバーの生成（サーバーインスタンスを作る）
3. ツールの定義（提供したい機能をツールとして作成）
4. ツールの実装（ツールが呼ばれた際に実行されるハンドラ関数を用意）
5. ツールの登録（サーバーにツールを登録して有効化）
6. サーバーの起動と接続待ち受け開始
7. クライアント（LLM）側からの接続テスト

それでは、順を追って具体的に見ていきましょう。

必要なツールと依存関係: Gemini CLIやGoモジュールの準備

まずプロジェクトディレクトリを作成し、go mod initでモジュールを初期化します。例えばmcp-demoというディレクトリを作り、そこでgo mod init mcp-demoを実行すると、go.modファイルが生成されGoのモジュール管理下に入ります。

次に、Gemini CLIをインストールしておきます（まだであれば）。Gemini CLIはnpmまたはHomebrewでインストール可能です。例えば:

# npmでグローバルインストールする場合 npm install -g @google/gemini-cli
インストール後、バージョン確認
gemini --version

Gemini CLIの設定や認証については公式ドキュメントに詳しいですが、最低限GoogleアカウントでのOAuth認証またはAPIキーの用意が必要です。初回起動時に指示に従ってセットアップしてください。

Gemini CLIはMCPクライアント（AIエージェント）として動作し、起動するとカレントディレクトリをスキャンして対話型プロンプトを提供します。今回はこのGemini CLIから我々のMCPサーバーに接続する形でツールを利用します。

なお、Gemini CLIを使わず独自にMCPクライアントを作ることも可能です。しかしGemini CLIはGoogle提供ということもあり、Gemini（モデル名）など高度なLLMとの接続や検索ツールの組み込みなど便利な機能を備えています。まずはGemini CLIを活用するのが手軽でしょう。

Goプロジェクトの初期化: モジュール設定とディレクトリ構成

プロジェクトが初期化できたら、ソースコードファイルを用意します。例えば簡単のためmain.go一つでサーバーの実装を完結させます。

ディレクトリ構成例:

mcp-demo/ ├── go.mod (Goモジュール設定ファイル) └── main.go (MCPサーバーの実装コード)

main.goには、前述のステップ2～6に沿ってコードを書いていきます。次章で実際の実装例を示しますが、ここでは概略を説明します。

まず、使用するパッケージをインポートします。MCP Go SDK（コミュニティ版の場合）はgithub.com/mark3labs/mcp-go/...以下にパッケージが分かれており、サーバー関連は.../server、プロトコル共通定義は.../mcpに含まれます。また、標準ライブラリのfmtやcontextも使用します。

次に、MCPサーバーインスタンスの生成です。server.NewMCPServer(name, version, ...options)という関数でサーバーを作成できます。名前とバージョンを指定し、オプションでツールの実行能力やフックを有効化できます。例えば:

// MCPサーバーの生成 s := server.NewMCPServer("DemoServer", "1.0.0", server.WithToolCapabilities(true))

この例では名前を"DemoServer"、バージョンを"1.0.0"としてサーバーを作成し、オプションでTool呼び出し機能を有効化しています。

簡単なMCPサーバー実装: Hello Worldツールを追加する例

MCPサーバーに登録する最初のツールとして、「Hello World」機能を追加してみましょう。これは入力として人名を受け取り、”Hello, 名前!”という挨拶文を返すシンプルなツールです。MCPサーバーにおけるツールは、名前・説明・引数定義・実行時のハンドラで構成されます。

まず、ツールの定義を行います。コミュニティ版SDKではmcp.NewTool関数でツールを作成できます。例えば:

// "hello_world"ツールの定義 tool := mcp.NewTool("hello_world", mcp.WithDescription("指定した名前に挨拶を返す"), mcp.WithString("name", mcp.Required(), mcp.Description("挨拶する相手の名前"), ), )

上記ではツール名を"hello_world"とし、説明とパラメータを設定しています。mcp.WithString("name", ...)により文字列型の引数nameを定義し、Required()で必須指定、Description()で引数の説明を付与しています。このようにツールのインタフェース（名前・引数など）を宣言することで、LLM側はどんなツールでどんなパラメータが必要かを事前に知ることができます。

次に、ツールのハンドラ実装です。ハンドラは、LLMからそのツールが呼ばれた際に実行される処理を記述した関数です。先ほど定義したhello_worldツール用に、以下のような関数を用意します。

func helloHandler(ctx context.Context, req mcp.CallToolRequest) (*mcp.CallToolResult, error) { // 引数"name"を取得 name, err := req.RequireString("name") if err != nil { return mcp.NewToolResultError(err.Error()), nil } // 挨拶メッセージを結果として返す return mcp.NewToolResultText(fmt.Sprintf("Hello, %s!", name)), nil }

このハンドラは、まずRequireString("name")で呼び出し時に渡された名前を取得し、エラーチェックを行っています。その後、mcp.NewToolResultTextで文字列メッセージとして結果を生成し返しています。MCPではツール実行結果をJSON-RPC経由で返す必要があるため、SDKのヘルパー関数であるNewToolResultTextやNewToolResultErrorを使って適切なレスポンスオブジェクトを作る仕組みになっています。

ツール定義とハンドラが用意できたら、サーバーへのツール登録を行います。先ほど生成したMCPサーバーインスタンスsに対して、s.AddTool(tool, helloHandler)を呼び出すだけで登録完了です。これでサーバーは"hello_world"という名前のツールを認識し、LLMからそのツールが呼ばれた際には対応するハンドラを実行するようになります。

最後に、サーバーの起動です。MCPでは通信方式として標準入出力（STDIO）とHTTP（ストリーミングHTTP）が定義されています。まずは手軽なSTDIOを使い、server.ServeStdio(s)を呼んでサーバーを起動します。

// 標準入出力でサーバー起動し、LLMからの接続を待機 if err := server.ServeStdio(s); err != nil { fmt.Fprintf(os.Stderr, "サーバーエラー: %v\n", err) }

このコードをmain.goにすべて書き終えたら、go run main.goでサーバーを起動できます。ターミナル上でこのコマンドを実行すると、MCPサーバーがバックグラウンドで待ち受けを開始し、標準入力からのJSON-RPCメッセージを待つ状態になります。

MCPサーバーの起動とテスト: 標準入出力での動作確認

作成したMCPサーバーを実際に動かし、想定通りツールが機能するかテストしてみましょう。先ほど述べたように、go run main.goを実行するとMCPサーバーが起動します。ただし何も表示されないため、本当に動いているのか分かりづらいかもしれません。別のターミナルを開いてテストを行いましょう。

テスト方法はいくつかありますが、ここではGemini CLIを使った方法を紹介します。まずGemini CLIに我々のローカルMCPサーバーを認識させる必要があります。そのために、ホームディレクトリに作成されたGemini CLIの設定ファイル ~/.gemini/settings.json を開き、"mcpServers" セクションに新たなエントリを追加します。

{ "mcpServers": { "demo": { "command": "/path/to/your/mcp-demo/bin" } } }

上記は例ですが、"demo"という任意のキー名で我々のMCPサーバーを登録しています。commandには先ほど起動したサーバープロセス（実行ファイル）のパスを指定します。Gemini CLIはこの設定に基づき、起動時に該当コマンドを実行してMCP接続を確立しようとします。設定を保存したら、一度Gemini CLIを再起動してください。

Gemini CLI再起動後、内部でMCPサーバーへの接続が行われ、正常にいけば「hello_world」ツールが利用可能になります。実際にGemini CLI上で以下のように入力してみましょう。

ユーザー: hello_worldツールを使って"Alice"に挨拶して

すると、バックエンドでMCPサーバー上のhello_worldが呼び出され、ハンドラが”Alice”を受け取って”Hello, Alice!”という結果を返すはずです。Gemini CLI上のAIはその結果を受け取り、ユーザーに回答として表示します。

標準入出力を使ったこの方法では、Gemini CLIと我々のMCPサーバーが同一マシン上で動いている必要があります。複数のMCPサーバーを登録することも可能で、設定ファイルのmcpServersに複数エントリを並べれば、AIはそれら全てのツールを使えるようになります。

なお、MCPサーバーはHTTPで動作させることもできます。HTTPモードにするとサーバーをローカル外から呼び出せるようになり、Cloud Runなどにデプロイしてインターネット経由でAIエージェントに機能を提供することも可能です。その場合はGemini CLIの設定で"httpUrl": "http://...:8080"のようにURLを指定して登録します。

ひとまず、これでローカル環境におけるMCPサーバーの構築と基本動作確認は完了です。

MCP公式Go SDKの設計思想と基本的な使い方：アーキテクチャの特徴とシンプルなAPI利用方法を詳しく解説

MCP公式SDKの概要と設計方針: クライアント・サーバー両対応のアーキテクチャ

ここからは、先ほどまで主に扱ってきたコミュニティ実装(mcp-go)ではなく、MCP公式のGo SDKに焦点を当てて解説します。公式SDKはModel Context Protocolプロジェクトによって管理されており、Googleとも協力して開発が進められています。公式SDKの大きな特徴の一つは、MCPクライアントとサーバーの双方を実装できるようになっている点です。すなわち、ひとつのSDKで「外部ツールを提供する側」と「LLMからツールを呼び出す側」の両方の機能をサポートしています。

公式SDKの内部構造は、複数のパッケージに分かれています。例えばツールやリソースなどプロトコルのコア定義部分、サーバー実装部分、クライアント実装部分、といった具合です。この分離により、必要な機能だけをインポートして使える柔軟性があります。また公式SDKの設計段階では、コミュニティによる既存のGo実装（前述のmcp-go）が大いに参考にされました。実際、公式SDKのリポジトリにはEd Zynda氏（mcp-go作者）への謝辞が記されており、既存実装の知見を取り入れつつ洗練されたアーキテクチャになっていることが伺えます。

プロトコル仕様面では、公式SDKもMCPの最新仕様に追随しています。2025年4月時点のMCP仕様(2024-11-05版)では、通信方式としてSTDIOとストリーム可能HTTPが定義され、OAuth2.1に基づく認証フレームワークの追加などの拡張が取り込まれています。公式SDKはこれらの変更にも対応すべく積極的にアップデートされており、信頼性の高い基盤を提供することを目標としています。

シンプルで直感的なAPI: 最小限のコードでMCP機能を実装

公式Go SDKの設計思想として特筆すべきは、「シンプルで直感的なAPI」です。開発者が可能な限りプロトコルの細部を意識せずに、自分のビジネスロジックに集中できるよう配慮されています。例えば、MCPサーバーを立ち上げツールを登録するまでに必要なコード行数は非常に少なくて済みます。前章で示したコミュニティ版のコード例とほぼ同様の手順で、公式SDKでもサーバー構築が可能です。

具体的には、公式SDKでもNewMCPServerやNewToolといった関数が提供されており、直感的にオブジェクトを組み立てられます。ボイラープレート（定型コード）が極力排除されているため、Hello World程度のサーバーであればほんの数十行で実装できてしまいます。これは設計上、Go言語の利点である型システムを活かし、安全かつ簡潔に書けるようインタフェースが整えられているからです。

さらに、公式SDKにはデフォルト設定やヘルパー機能も充実しています。たとえばツール呼び出し時のエラーハンドリングや、サーバー実行中のパニック捕捉（リカバリ機能）などもオプションで利用できます。これらはオープンソースコミュニティからのフィードバックを受けて追加された機能であり、現場での使い勝手が考慮されています。

公式SDKのREADMEやドキュメントにはシンプルなサンプルコードが記載されており、初学者でもすぐに試せるようになっています。例えば、数行で電卓機能（簡単な四則演算ツール）を追加するコード例などが掲載されており、APIの直感性を実感できるでしょう。

MCPの要素を表現する主要構造体: Tool・Resource・Promptの扱い

MCPのサーバー機能は、「ツール (Tools)」「リソース (Resources)」「プロンプト (Prompts)」という3つのプリミティブ（基本要素）で構成されています。公式SDKでもこれらを表現するための構造体やクラスが用意されています。

• Tool: LLMが呼び出せる操作（関数）のことです。例えばファイル読み書きやWeb検索、今回の挨拶のような機能もツールに該当します。公式SDKではToolを定義するためのビルダー関数や、Tool呼び出しリクエスト/結果を扱う型が提供されています。
• Resource: LLMに提供するデータです。例えば「プロジェクトのREADMEファイル」や「データベースの一部」などをリソースとしてExposeできます。公式SDKではNewResource等の関数でリソースを登録可能で、LLMはそれを読み込んでコンテキストとして利用できます。
• Prompt: あらかじめ用意されたプロンプトテンプレートです。ユーザーが対話的に選択できるメニューや定型コマンドのような位置づけで、公式SDKでもプロンプトを定義・登録する仕組みがあります。

これら3要素を適切に組み合わせることで、MCPサーバーはLLMに対して豊富なコンテキストと操作手段を提供できます。公式SDKでは各要素を操作するAPIが整理されており、高水準のインターフェース経由で扱えるため、開発者は低レイヤーのJSON-RPCメッセージ構造を意識せずに実装を進められます。

例えば公式SDKでは、ツールを表現する型に対して説明文や引数定義をメソッドチェーンで設定できるようになっていたり、リソースに関してもMIMEタイプや説明を簡単に付与できるよう設計されています。これにより、MCPの各機能を漏れなく簡潔にプログラミングできるようになっています。

型安全性と拡張性: Goの特徴を活かした堅牢な設計

Go言語を用いたSDKである以上、型安全性と拡張性も重要な要素です。公式SDKはジェネリクスなど最新のGo言語機能は多用していませんが、その代わりインタフェースと構造体、メソッドの組み合わせにより堅牢性を確保しています。

例えば、先ほどのツールハンドラの例ではreq.RequireString("name")のように、引数の型チェックと存在確認をワンライナーで行えるAPIが提供されていました。これは内部的に型アサーションやエラーハンドリングを含んでおり、開発者がミスを犯しにくいデザインになっています。同様に、NewToolResultTextも結果オブジェクト生成を抽象化しており、直接JSONを生成するのではなく型付きオブジェクト経由で安全に結果を返せます。

拡張性の面では、Hook（フック）機能やMiddleware的な仕組みも検討されています。実際、公式SDKにはサーバー起動時にフックを登録できるserver.WithHooks(...)オプションがあり、ツールの前後処理やエラーロギングなどを統一的に追加できます。また複数ツール間で共通する処理（認証やレート制限など）をまとめて適用することも可能です。

さらに、公式SDKはマルチプラットフォーム・マルチ言語のMCPエコシステムにおける一部でもあります。他言語（PythonやTypeScriptなど）の公式SDKとも整合性を保つよう設計されているため、将来的に異なる言語のMCPサーバー/クライアントと連携する場合でも、共通した概念で理解・拡張できるでしょう。

公式SDKの基本的な使い方: Hello Worldツールを追加する例

最後に、公式SDKを使った基本的なツール追加方法を簡単におさらいします。やること自体はコミュニティ版の場合と大きく変わりません。

1. SDKをプロジェクトにインポートする（例：import "github.com/modelcontextprotocol/go-sdk/server"等）。
2. MCPサーバーを作成する（NewMCPServerを使用）。
3. ツールを定義する（NewToolなどで名前や引数を設定）。
4. ハンドラ関数を実装する。
5. サーバーにAddToolでツールとハンドラを登録する。
6. ServeStdioやHTTPサーバー起動関数でサーバーを開始する。

公式SDKでも基本的な呼び出し方は共通なので、詳細なコードは割愛しますが、要領は前章までのコミュニティ版での実装とほぼ同じです。異なる点があるとすれば、パッケージ名や関数名が若干異なる可能性があるくらいでしょう（例えば公式SDKではパッケージ階層が異なるかもしれません）。

実際に公式SDKのリポジトリには examples/ ディレクトリがあり、簡単なツール追加例が公開されています。それらも参照しながら進めると理解が深まるはずです。公式SDKはまだ新しいプロジェクトではありますが、コミュニティの知見が取り入れられているため、扱いやすさと信頼性のバランスが取れた実装になっていると言えるでしょう。

MCP Go SDKと他のGoライブラリ（例：mark3labs/mcp-go）の比較検証：機能・設計思想・性能面の違いを徹底分析

公式SDKとコミュニティ版の位置づけ: Google支援とコミュニティ主導の違い

現在、Go言語向けのMCP SDKには大きく分けて「公式SDK」と「コミュニティ版SDK(mcp-go)」の二つがあります。まず開発体制の違いについて整理しましょう。

コミュニティ版(mcp-go)は、有志開発者であるEd Zynda氏により開始されたプロジェクトで、早い段階からMCP対応のGo実装を提供してきました。その結果、多くのスターを獲得し（約7kスター）、コミュニティの支持を集めています。開発やメンテナンスはオープンに進められ、ドキュメントサイト（mcp-go.dev）で詳細なガイドやAPIリファレンスが提供されるなど、利用者目線の整備がなされています。

公式SDKは、Model Context Protocolの公式プロジェクトとしてGoogleのエンジニアも関与して開発されている実装です。コミュニティ版で培われた知見を踏まえつつ、MCP標準の将来像を見据えた設計が行われています。公式という安心感もあり、企業利用などを念頭においた品質管理や長期的なサポートが期待できます。ただし現時点ではスター数は約1.6k程度で、コミュニティ版ほどの広がりはまだこれからといったところです。

API設計と機能の違い: 公式SDKとmcp-goが提供する機能比較

次に、両者の提供するAPIや機能の比較です。基本的なMCPの仕様に沿った部分（ツール・リソース・プロンプトの管理、STDIO/HTTP通信、JSON-RPCハンドリングなど）は両SDKで大きな差はありません。実際、公式SDKはmcp-goのデザインを踏襲しているため、NewMCPServerやAddToolといった関数名・概念も共通しており、移行も容易です。

一方で細かな設計思想やユーティリティの面では差異が見られます。コミュニティ版mcp-goは先行して開発が進んだこともあり、Goらしいシンプルさを追求しつつ実装されています。例えば前述のようにチェーンメソッドでToolやResourceを定義できる洗練されたAPIが特徴でした。公式SDKも使い勝手では劣りませんが、コミュニティ版の使い慣れた開発者から見ると若干パッケージ構成が異なる点に最初戸惑うかもしれません。

機能面で注目すべきは、対応している最新仕様や拡張機能です。公式SDKは仕様策定側と連携しているため、新しいMCPの拡張（例えば認証フレームワークやストリーミングHTTPなど）への対応が速い傾向にあります。一方コミュニティ版も追随してアップデートされていますが、非公式ゆえに対応タイミングに多少のラグが出ることも考えられます。

また、ツールのカスタマイズ性やフック機能などでは両者大きな違いはありません。mcp-goにも公式SDKにも、ツール呼び出し前後のフック、パニックリカバリ、マルチトランスポート対応などが備わっています。ただしコミュニティ版は独自の拡張（例えばロギングのインタフェースや、一部ユーティリティ関数の追加など）がある場合があります。

パフォーマンスと安定性の比較: 実装効率や信頼性の観点

パフォーマンス面では、どちらのSDKもGo言語で記述されていることから基本的に高速で効率的です。標準入出力やHTTP上でJSON-RPCメッセージをやり取りするというプロトコル仕様上、オーバーヘッドも小さいため、実行速度に顕著な違いは報告されていません。内部実装を見ると、JSONのシリアライズ/デシリアライズなどにおいても標準ライブラリや最適化された実装を用いており、どちらも十分な性能を発揮するでしょう。

安定性・信頼性の観点では、公式SDKにはGoogleの厳格なコードレビューやテストが適用されている点が安心材料です。公式SDKのリポジトリではCIによるビルドテストや複数プラットフォームでの検証も行われています。また、マルチスレッド（Goルーチン）環境での安全性にも配慮されており、複数のツール呼び出しが並行して発生しても適切に捌ける設計になっています。

コミュニティ版mcp-goも多数のユーザーによって実運用で鍛えられており、Issueトラッカーには活発な議論とバグ修正の履歴があります。GitHubのIssuesやDiscussionsを覗くと、利用者からのフィードバックに対応し改善が繰り返されてきたことがわかります。したがって、現時点で性能・安定性においてどちらが有意に優れているということはなく、用途に応じて選択して問題ないレベルと言えます。

ドキュメントと使い勝手: 学習コストやサンプルの充実度

開発者にとって重要なドキュメント面でも違いがあります。コミュニティ版mcp-goは専用のドキュメントサイトが用意されており、「Getting Started」から「Advanced Features」まで丁寧に解説されています。サンプルコードも豊富で、初めてMCPに触れる人でもステップバイステップで学べる構成です。

一方、公式SDKはリポジトリのREADMEやexamples/ディレクトリに基本的な情報があるものの、現時点では単独のリファレンスサイトは存在しないようです。その代わりMCP全体の公式サイトやSpec文書にリンクが貼られており、プロトコル仕様を参照しながらSDKを使う形になっています。学習コストという観点では、コミュニティ版の方が手厚いドキュメントにより低く抑えられている印象です。

使い勝手については、これはほぼ好みの問題になるでしょう。前述の通りAPIの感触はよく似ています。強いて言えば、コミュニティ版を先に使っていた人は公式SDKのパッケージパスや初期設定に多少戸惑うかもしれません。しかし一度慣れてしまえば大差はなく、むしろ公式SDKのほうが今後の標準となっていく可能性が高いため、将来性を考えて公式に寄せておくという判断も十分あり得ます。

プロジェクトの活発度と将来性: 開発コミュニティと標準化動向

最後に、コミュニティ面と将来性についてです。コミュニティ版mcp-goは上述の通り非常に活発で、多くのコントリビュータがIssueやPull Requestを投げています。リリース頻度も高く、新機能追加や不具合修正が迅速です。ユーザーフォーラム的な役割も果たしており、MCPに関する知見を得るにはコミュニティ版のGitHubをフォローするのが有益でしょう。

公式SDKはプロジェクト自体がまだ新しく、コミュニティ版ほどの賑わいはこれからです。しかしGoogleが関与しているという点で信頼感があり、企業利用の場面では公式SDKが採用されるケースが増えるかもしれません。また、MCP全体が今後標準プロトコルとして広まっていけば、公式SDKがデファクトスタンダードとなっていく可能性も高いです。その際にはコミュニティ版も公式に歩調を合わせる形で統合・収束していくことも考えられます。

現状では両方の実装が併存していますが、互いに良い刺激を与え合いMCPエコシステム全体を盛り上げていると言えるでしょう。開発者としては、自身の目的や好みに応じて選択すればOKです。どちらを選んでも、MCPという強力な仕組みを通じてAIエージェントを拡張できるという本質的な価値は変わりません。

MCPと疎結合なAIエージェントアーキテクチャ：LLMと外部ツールの柔軟な連携を可能にする設計とは？

従来の密結合なAIシステムの課題: ツール実装ごとの非標準化

ここまでMCPの具体的な技術について述べてきましたが、改めてMCPがもたらす「疎結合なアーキテクチャ」の価値について考えてみます。まず、MCP登場以前の従来型AIシステムにおける課題を整理しましょう。

従来、多くのAIアプリケーションで外部ツールを使う場合、その手法は各フレームワークやプロダクト毎にまちまちでした。例えば、あるプロジェクトではPythonのLangChainを使ってツールを組み込み、別のプロジェクトでは独自にREST APIを呼び出すコードを書き、また別ではプラグインシステムを実装する、といった具合です。それぞれの実装が密結合（タイトカップル）しており、共通のインタフェースがないため再利用性が低い問題がありました。

具体例を挙げると、LangChainでツールを追加したエージェントを別のシステムに移植しようとしても、LangChainに依存するコードを一から書き直す必要がありました。また、AIとツールが同じプロセス内で動作する設計では、セキュリティや障害切り分けの面でもリスクがありました。ひとつの部分に問題があるとシステム全体に影響が及び、スケーリング（負荷分散）も困難です。

MCPによる標準化: AIとツール間のインタフェース統一

こうした課題に対し、MCPはAIとツール間のインタフェースを統一するソリューションとして現れました。MCPを使うことで、LLMから見た外部ツールの呼び出し方法がすべて同じ枠組みに収まります。LLMは「このツールを使いたい」と思ったら、決められたJSON-RPCのメッセージ形式でリクエストを送り、ツール側も決められた形式で応答するだけです。

この標準化により、LLM側は相手がどんなプログラミング言語やどんな実装方法で作られたツールであっても気にする必要がなくなります。MCPクライアントさえ実装していれば、背後のサーバー（ツール群）がJavaで書かれていようとGoで書かれていようと、相互運用が可能です。まさに「USB-Cがデバイス接続を標準化した」のと同じように、MCPがAIとツールの接続方法を標準化したと言われる所以です。

この統一インタフェースの恩恵として、LLMアプリケーション開発の効率と信頼性が大幅に向上します。開発者は各ツールごとに異なる統合方法を学ぶ必要がなく、MCPの規約に沿ってツールを追加・削除するだけで済みます。LLM側のコードは一切変更せずに、新しい機能をシステムに組み込めるわけです。

疎結合がもたらす利点: 開発効率と柔軟性の向上

MCPによる疎結合（ロースカップル）設計が具体的にもたらす利点を挙げてみます。

• 開発のモジュール化: ツールごとに独立したMCPサーバーとして開発・デプロイできるため、機能追加や修正が他部分に影響しにくい。特定のツール開発を別チームに委任することも容易。
• 再利用性の向上: 一度作ったMCP対応ツールは、他のどんなMCPクライアント（AIエージェント）からも利用可能。例えば社内で作成した「データベース問い合わせツール」を複数プロジェクトのAIに共有できる。
• スケーラビリティ: ツールの負荷が高い場合、そのツール用MCPサーバーだけ別サーバーにスケールアウト（複製）したり、マイクロサービス的に管理したりできる。LLM本体とは独立にスケーリング戦略を取れる。
• 故障耐性・セキュリティ: あるツールで不具合やクラッシュが起きても、MCPサーバープロセスが隔離されていればAI本体に影響を与えない。権限管理もサーバー単位で行えるため、危険な操作には事前認証を挟むなど安全策を講じやすい。

要するに、疎結合なアーキテクチャはシステム全体を柔軟かつ頑健にします。一つひとつのMCPサーバー（ツール群）が独立しているので、用途に応じた組み合わせや配置換えも簡単です。例えば、開発中はローカルPC上でツールを動かしつつ、将来的にその一部をクラウド上の高速サーバーに移す、といった段階的な拡張も容易です。

プラグイン的拡張の実現: MCPサーバーを追加・削除するだけで機能拡張

疎結合アーキテクチャの醍醐味は、プラグインのようにAIに機能追加できる点です。MCPサーバーは必要に応じて後から追加したり、不要になれば削除したりできます。LLM側はMCPクライアントさえ実装していれば、動的に新しいサーバー（ツール群）を発見して利用できます。先述のGemini CLIの例では、設定ファイルに新しいMCPサーバーのエントリを書き足すだけで、そのサーバーが提供する全ツールが即座に利用可能になりました。

これは、まさにブラウザにプラグインを入れて機能強化するのと似ています。AIエージェントに「データ分析能力をプラスしたい」と思えば、データ分析用のMCPサーバーを用意して繋ぐだけ。逆に「この機能はもう使わない」となれば設定から外すだけで済み、AIエージェント自体のコードを書き換える必要がありません。

また、この拡張性はAIエージェントの個性化にも役立ちます。例えば、あるエージェントはプログラミング支援系のツールサーバーだけ繋いで「コーディングAI」にし、別のエージェントは経理サポート系のツールサーバーを繋いで「会計AI」にするといったカスタマイズが容易です。必要なツールセットを選んで繋ぎ替えるだけで、エージェントの役割を柔軟に変えられるのです。

このようなプラグイン的拡張の仕組みは、AIエージェントが様々なドメインで活躍する未来を見据える上で非常に重要です。MCPに対応したツールサーバーのエコシステムが広がれば、企業やコミュニティごとに最適化されたAIエージェントを構築することが可能となるでしょう。

他プロトコルとの比較: LangChain等との違いと使い分け

疎結合アーキテクチャを語る際に、LangChainのような既存フレームワークとの比較に触れておくことも有益です。LangChainはPython発のライブラリで、LLMにツールを使わせるためのフレームワークとして広く知られています。しかしLangChainの場合、ツールはエージェント内部に組み込まれる形で、コードレベルで統合されます。ゆえにLangChainを用いたシステムは、そのエージェントとツール群が比較的密結合な構成になります。

一方MCPは前述の通りプロセス間通信（JSON-RPC）を用いた疎結合です。LangChain的アプローチが「同じプログラム内にツール機能を組み込む」のに対し、MCPは「別プログラムとしてツール機能を提供し連携する」という違いがあります。どちらが優れているというより、用途によって使い分けが考えられます。

• LangChain的: 単一のアプリ内で完結し、Python環境で統一したい場合。低レイテンシでのツール呼び出しが必要な場合。
• MCP的: 複数言語・複数プロセスで大規模にシステムを構築したい場合。分散アーキテクチャやマイクロサービス志向の設計にしたい場合。

将来的には、LangChainとMCPを組み合わせることも考えられるでしょう。実際、Azure OpenAI ServiceでMCPクライアントを実装した例では、既存システムに後付けでMCP対応を施す試みが報告されています。各プロトコルやフレームワークの強みを活かしつつ、疎結合と密結合を適材適所で組み合わせることが、現実的な解となる場面もあるかもしれません。

いずれにせよ、MCPが提示した疎結合アーキテクチャはAIエージェント開発に新たな選択肢と可能性をもたらしました。今後バージョンアップが進みセキュリティ面の整備が進めば、インターネット越しにMCPサーバーを公開しAIを拡張することも当たり前になっていくでしょう。

Gemini CLIとの連携方法：MCPサーバーの登録設定とAIエージェントへの統合利用【完全ガイド】

Gemini CLIとは: ターミナル向けAIエージェントの概要

Gemini CLIは、Googleがオープンソースで公開した対話型のAIエージェントです。ターミナル上で動作し、プロンプトを通じてコードの理解・生成やファイル操作など様々なAI支援を行ってくれます。Gemini 2.5など大規模モデルをバックエンドに利用しつつ、無料枠として毎分60リクエスト・日1000リクエストまで使えるという特徴があります。

Gemini CLIにはあらかじめGoogle検索やファイル読み書き、シェルコマンド実行などのビルトインツールが備わっています。例えばGoogleSearchやWebFetchといったコマンドを通じ、インターネット検索やウェブ上の情報取得が可能です。また、ChatGPT的なコード解説・生成も得意としており、開発者にとって日常的な相棒となり得る存在です。

Gemini CLIが優れている点の一つは、その拡張性にあります。Gemini CLIは標準でMCPに対応しており、外部のMCPサーバー（カスタムツール群）を統合できる設計になっています。まさにここが本記事のテーマであるMCP Go SDKと交わる部分です。

Gemini CLIとMCPの関係: 外部ツール連携を可能にする仕組み

Gemini CLIはMCPクライアントとして機能します。起動時に設定ファイル~/.gemini/settings.jsonを読み込み、そこに登録されたMCPサーバーへ自動で接続を試みます。各MCPサーバーから取得したツール一覧は、Gemini CLI内であたかも最初から備わっているコマンドのように扱われます。ユーザーが何らかの問いかけをした際、AIは必要に応じてそれら外部ツールを呼び出し、結果を使って回答を生成します。

この仕組みにより、Gemini CLIはプラットフォームのように振る舞います。デフォルトでは前述の検索など一般的なツールが入っていますが、開発者は独自のMCPサーバーを用意して登録することで、そのGemini CLIを自分専用に強化できます。例えば先述のhello_worldツールを登録すれば、Gemini CLIはユーザーから「hello_worldして」と頼まれれば裏でMCPサーバーのハンドラを呼び出し、結果を返すようになります。

Gemini CLIとMCPサーバーは別プロセスですので、相互のやりとりはJSON-RPCメッセージで行われます。Gemini CLI側から見ると、MCPサーバーはローカルにせよリモートにせよ、一種のプラグインプロセスとして接続されているイメージです。その通信はMCP仕様で標準化されているため、Gemini CLIは統一的な方法で複数のMCPサーバーを扱えます。

Gemini CLI上では、内部でMCPサーバー上のツールを呼び出す際に特別なコマンドをユーザーが入力する必要は基本的にありません。AIが適切にツールを選択して使ってくれます。ただ、ツールを使うよう促すプロンプト（指示）を書いてやると効果的です。例えば「Use the godoctor tool to retrieve documentation」のように言えば、自前のgodocツールを優先して使ってくれるでしょう。

設定ファイルでのMCPサーバー登録方法: ~/.gemini/settings.jsonの編集

具体的なGemini CLIとMCPサーバーの連携手順を説明します。肝となるのは設定ファイル~/.gemini/settings.jsonの編集です。前述の通り、このJSONファイルに"mcpServers"というオブジェクトがあり、そこに任意のキー名でMCPサーバーを登録します。

例として、ローカルで起動中のgodoctorというMCPサーバー（Goコードアシスタント用ツールサーバー）を登録する場合、設定ファイルの該当箇所は以下のようになります。

"mcpServers": { "godoctor": { "command": "/Users/username/go/bin/godoctor" } }

ここではキー名"godoctor"で、コマンド実行パスとしてローカルにビルドした実行ファイルのパスを指定しています。commandの代わりに"httpUrl": "http://..."を指定すればネットワーク経由（HTTP接続）でのサーバー利用も可能です。設定を保存したら、Gemini CLIを再起動しましょう。

再起動後、Gemini CLIはバックグラウンドでgodoctorサーバーを起動し、MCPハンドシェイクを行います。正常に接続できれば、godoctorサーバーが提供するツール一覧（例: godocツール等）がGemini CLIに通知されます。Gemini CLI側ではそれらを内部コマンドとして認識し、ユーザーとの対話の中で必要に応じ使う準備が整います。

以上が設定ファイルでMCPサーバーを登録する方法です。ポイントは、Gemini CLIは複数のMCPサーバーを同時に登録できるということです。mcpServers内に複数のキーを設ければ、例えば"tools1"と"tools2"といった複数のサーバーを並行して利用できます。AIはその全てのツールをリソースとして使えるため、非常に強力です。

Gemini CLIからMCPツールを利用する方法: 実行例と注意点

MCPサーバーの登録が済んだGemini CLIでは、ユーザーは特に意識せずともAIが裏でツールを活用してくれるようになります。しかし、初回はきちんとツールが動くか試してみたいでしょう。そこで簡単な利用例を紹介します。

例えば先ほど登録したgodoctorサーバーには、godocというツールが含まれていたとします。これは指定したGoパッケージやシンボルのドキュメントを返すツールです。ユーザーとしてGemini CLIに以下の質問をしてみます。

ユーザー: 「fmt」パッケージのドキュメントを表示して

通常であればAIはウェブ検索や自身の訓練データから回答しようとしますが、godocツールが使える場合、AIはそれを呼び出す判断を下すかもしれません。裏ではGemini CLIが{"method": "tools/call", "params": {"name": "godoc", ...}}というJSON-RPCリクエストをgodoctorサーバーに送り、ドキュメント文字列を取得します。そして、その結果を基にユーザーへ回答を返してくれるでしょう。

このように、MCPツールの利用は基本的にAIに任せる形になります。ただ、思うようにAIがツールを使ってくれない場合は、「〇〇ツールを使って」といった指示をプロンプトに追加すると効果的です。Gemini CLIではツールを使う/使わないもAIの判断に委ねられていますが、ユーザーから明示的に促すことでその意図を伝えられます。

最後に注意点として、Gemini CLIとMCPサーバーの組み合わせでは設定や環境を整える必要があることを覚えておきましょう。特にHTTP接続を行う場合、ファイアウォールの設定やポート開放、またURLを正しく指定することが重要です。ローカル環境であればcommand指定がシンプルですが、サーバーをクラウドに置いて使う場合はHTTPS対応や認証の仕組みも検討すべきです。

以上がGemini CLIとMCPサーバーの連携方法の概要です。適切に設定すれば、自作のツール群をGemini CLIという強力なインターフェースから自在に操ることができるようになります。

Gemini CLI連携のユースケース: 開発効率化やカスタムAIエージェントの構築

MCPとGemini CLIの組み合わせは、実践的に様々なユースケースで活躍します。その一部を紹介して本節を締めくくります。

• コーディングアシスタントの強化: Go言語開発に特化したツール（コンパイル、テスト、自動リファクタリングなど）をMCPサーバーとして用意しGemini CLIに連携することで、コードレビューからドキュメント生成まで行える究極のコーディングAI環境を構築。
• 運用自動化エージェント: サーバー監視やデプロイ操作のスクリプトをツール化し、Gemini CLIに繋ぐ。対話形式で「サーバーのCPU使用率を確認」「コンテナを再起動して」などと指示すれば、裏で必要なコマンドを実行して報告してくれるDevOpsエージェントとして機能。
• ドメイン特化AI: 医療AIや金融AIなど専門分野向けに、それぞれの分野のデータベース検索や計算ツールをMCP化。Gemini CLIにそれらを統合し、専門知識にアクセスできるカスタムAIチャットボットを作成。

このように、Gemini CLI × MCPの仕組みは応用範囲が広大です。プログラミングだけでなく、インフラ運用や業務支援、研究開発まで、アイディア次第で自分専用のAIエージェントを作り上げることができます。その際の要となるのがMCP Go SDKであり、Goの高性能と安全性を活かしたツール開発が土台にあることは言うまでもありません。

MCPでよく使うツール（godoc, hello_worldなど）の追加方法：godocやhello_worldなどカスタムツールをMCPサーバーに登録する手順を解説

Gemini CLI標準ツールとカスタムツール: 組み込み機能との違い

最後に、具体的によく利用されるツール例としてgodocやhello_worldの追加方法について触れます。Gemini CLIには前述のように標準でいくつかツールが組み込まれていますが、カスタムツールはそれらと同様の手順で利用可能にできます。ただし、自分で実装する必要があるという点が異なります。

標準ツールはGemini CLIにビルトインで用意されており、インストールすればすぐ使えます。一方カスタムツールは、開発者自身がMCPサーバー側に実装・登録しなければなりません。幸い、MCP Go SDKを使えばその実装は難しくありません。以下では例としてgodocとhello_worldを取り上げ、どのようにMCPサーバーに追加するかの手順を解説します。

godocツールとは: Goドキュメント検索ツールの機能

godocツールは、Go言語のドキュメントを検索・表示するためのツールです。具体的には、標準のgo docコマンドを呼び出して、その出力結果をLLMに返す役割を持ちます。Gemini CLIのコーディングワークショップでは、このgodocツールを組み込んだgodoctorサーバーを構築する例が紹介されています。

機能的には、必須のpackage引数（パッケージ名）と任意のsymbol引数（シンボル名）を受け取り、それに該当するドキュメント文字列を返します。たとえばpackage="fmt"で呼べばfmtパッケージの概要ドキュメントを、package="fmt", symbol="Println"で呼べばfmt.Println関数のドキュメントを取得できます。

Gemini CLIにこのgodocツールを組み込むと、AIはコード中で不明な構文や標準ライブラリの説明が必要になった際に、このツールを使って正確なリファレンスを引いてくれるようになります。Web検索より信頼性の高い情報源（ローカル環境のドキュメント）を使うことで、回答の正確性が向上する効果があります。

hello_worldツールとは: サンプル挨拶ツールの目的

hello_worldツールは、本記事でも何度か登場したシンプルな例です。一言で言えば「こんにちは」を言うだけのツールですが、MCPの仕組みを理解する上で格好のサンプルになります。

目的は入力として人名を受け取り、”Hello, 名前!”という挨拶結果を返すことです。これはLLM単体でも可能なことですが、MCPツールとして用意することでLLMに明示的な機能追加を行ったことになります。先ほど実装したコードでは、このhello_worldツールをMCPサーバーに登録し、Gemini CLIから呼び出すデモを行いました。

hello_worldツールのような簡単な機能でも、MCPに組み込む意味はあります。それは、AIに確実な動作をさせる点です。LLMに単に「Helloと挨拶して」と頼むだけでは、文脈によっては違う返事をするかもしれません。しかしhello_worldツールを呼ぶよう指定すれば、常に決まったフォーマットで挨拶するという信頼性が得られます。つまり、ツール化することでAIの出力を定型化・安定化できる効果もあるのです。

ツールの追加手順: NewToolでパラメータと説明を定義

では、これらgodocやhello_worldといったカスタムツールをMCPサーバーに追加する一般的な手順をまとめます。

1. ツールの企画: まず何をするツールか、その入力・出力は何かを決めます。godocなら「packageとsymbolを受け取りドキュメント文字列を返す」、hello_worldなら「名前を受け取り挨拶を返す」といった仕様です。
2. NewToolでツール定義: MCP Go SDKのNewTool関数を使い、ツール名・説明・引数を定義します。godocの場合、"godoc"という名前でpackage（文字列, 必須）とsymbol（文字列, オプション）という2つの引数を定義します。hello_worldの場合は"hello_world"にname（文字列, 必須）だけでした。
3. ハンドラ実装: ツールが呼ばれた際の処理を関数で記述します。godocならos/execパッケージでgo doc package symbolコマンドを実行し、その標準出力を読み取って結果文字列とします。hello_worldなら単に文字列連結するだけでした。ここで外部システムとの連携や複雑なロジックを実行できます。
4. サーバーに登録: 出来上がったToolとハンドラ関数をMCPサーバーにAddToolで登録します。これでサーバーがそのツールを認識します。
5. テスト: サーバーを起動し、Gemini CLIなどからツールを呼び出して期待通り動作するか確認します。呼び出し方は先述の通り、Gemini CLI経由が簡単ですが、直接JSON-RPCメッセージを送ってテストすることも可能です。

以上の手順で、新しいツールを次々と追加できます。MCP Go SDKは上記を繰り返し適用する形で複数ツール登録をサポートします。注意点としては、ツール名や引数名はユニークにすること、ツールが増えたらそれに伴いAI側（Gemini CLIの設定やプロンプトガイド）の調整も考えること、などがあります。

しかし基本的には、フォーマットに沿って実装を追加していくだけですので難しいことはありません。たとえば「ファイルを読み込んで内容を返すツール」や「HTTP APIに問い合わせるツール」なども、上記と同じ流れで簡単に作成できます。こうして作られたツール群はMCPサーバー上に蓄積していき、あなた専用のツールセットとなるでしょう。

AIエージェントへのツール認識: Gemini CLIに新ツールを認識させる方法

ツールをMCPサーバーに追加しただけでは、AIエージェントはその存在を知りません。Gemini CLIなどMCPクライアント側に、新ツールの存在を認識させる必要があります。その方法は前述した通り、settings.jsonにMCPサーバーを登録することです。サーバー自体を一度登録してしまえば、そのサーバー内の追加ツールは再起動時に自動で認識されます。

例えば、最初はhello_worldだけ持っていたサーバーにgodocツールを追加したとします。サーバーを更新（ツール追加）して再起動すれば、Gemini CLIは次回起動時にその変更を検出します。具体的には、MCPサーバーからクライアントへのtools/list応答で新しいツール情報が含まれるため、AIは新ツールgodocを利用候補に加えます。

Gemini CLIは起動ごとに各登録MCPサーバーへtools/listを問い合わせ、利用可能なツール一覧を取得する仕様になっています。したがって、サーバー側でツールを増やせば次回接続時に自動反映されるのです。開発中にツールを追加・調整する際は、一度Gemini CLIを再起動するか、/reloadコマンド（もし用意されていれば）で再読込するとよいでしょう。

さらに、AIに新ツールを効果的に使わせるためには「どんな時にそのツールを使うべきか」という指針を与えることも有用です。Gemini CLIではプロジェクトごとのGEMINI.mdファイルにガイドラインを書いてAIの振る舞いを調整できます。例えばgodocツールを追加した場合、「コードの質問ではまずgodocツールを使ってドキュメントを確認し、それでも不明な場合のみWeb検索せよ」といったルールをGEMINI.mdに記載できます。これによりAIが新ツールを適切に優先利用してくれるようになります。

総括すると、MCPでカスタムツールを追加する作業自体はGo言語で実装を足すだけですが、AIエージェント側でそれを認識・活用させるところまで考慮すると、設定調整やプロンプト工夫も含めた包括的な対応が必要です。しかしそれさえ整えば、自分好みの強力なAIアシスタントを作り上げることができるでしょう。

以上、代表的なツール例であるgodocとhello_worldを題材に、MCPツールの追加方法を解説しました。読者の皆さんも、ぜひMCP Go SDKを使ってオリジナルのツールを実装し、AIエージェントに新たなスキルを教え込んでみてください。MCPによるAIエージェント拡張の世界は、今まさに広がり始めたところです。その可能性は無限大であり、あなたのアイデア次第で次々と新しいユースケースが生まれることでしょう。