先に要点
MCP までは分かったけど、MCPサーバーって結局なにを作るの？
ツールやリソースって、どこに実装するの？
ここでつまずく人はかなり多いです。
MCP の総論を読むと便利そうに見えますが、実際に作る側へ回ると、MCPサーバーがどの役目を持つのか が急にあいまいになりやすいです。
この記事では、2026年4月12日時点で Model Context Protocol の公式 Architecture overview、Quickstart for server developers、TypeScript SDK、Python SDK の公開情報を確認しながら、MCPサーバー の役割、作り方、使いどころ、公開時の注意点まで初心者向けに整理します。
まず MCP 全体の概要から押さえたい場合は、MCPとは？仕組み・できること・便利な理由を初心者向けにわかりやすく解説 を先に読むと入りやすいです。
MCPサーバーとは何か
MCPサーバー は、AI アプリに対して この機能を使えます このデータを読めます と公開する側のプログラムです。
AI アプリ本体が何でも直接知っているわけではなく、必要な機能やデータをサーバー側から受け取る形で動きます。
公式の Architecture overview でも、参加者は host / client / server に分かれています。
初心者向けに言い換えると、役割はこうです。
- ホスト
AI アプリ本体です。エディタ、デスクトップアプリ、社内チャット AI などがここに当たります。 - クライアント
ホストの中で、各 MCPサーバー と接続する役です。 - サーバー
外の世界にある機能や情報を、MCP の形で見せる役です。
つまり、MCPサーバー は AI と外部機能の境界面 です。
ファイル、データベース、SaaS、社内API、チケット操作などを、AI から扱いやすい形へ変換して出す場所と考えると分かりやすいです。
MCPサーバーは何を公開するのか
公式仕様でコアとして整理されているのは、MCPツール、MCPリソース、MCPプロンプト です。
| 公開要素 | 役割 | 例 |
|---|---|---|
| ツール | AI が実行できる機能 | ファイル検索、Issue 作成、API 呼び出し、承認付き操作 |
| リソース | AI が読むためのデータ | 設計書、設定値、DB スキーマ、ログの要約 |
| プロンプト | 再利用しやすい指示テンプレート | 調査フォーマット、レビュー観点、報告テンプレート |
ここで大事なのは、読む と 実行する を分けて考えられることです。
最初から強いツールを公開するより、まずは MCPリソース 中心で始める方が安全なことも多いです。
どんな接続方式を選ぶのか
MCPサーバー を作るとき、早い段階で決めたいのが接続方式です。
代表的なのは stdio と Streamable HTTP です。
stdio が向く場面
- 手元のエディタやデスクトップアプリから使う
- まず動作確認したい
- 認証や公開範囲の設計を最小限にしたい
ローカルで起動してローカルで使う なら、最初は stdio がかなり入りやすいです。
公式 Quickstart でも、サーバー開発の入口として扱われています。
Streamable HTTP が向く場面
- 複数クライアントから共通利用したい
- サーバーとして別マシンで動かしたい
- 認証つきのリモート利用を前提にしたい
ただし、HTTP 化した瞬間に 普通の公開サーバー としての責任が増えます。
認証、公開範囲、ログ、Origin の扱い、到達範囲まで含めて設計した方が安全です。
作るときの流れ
公式の TypeScript SDK や Python SDK を見ると、作業の流れはだいたい共通しています。
実務では次の順で考えると事故が減ります。
1. 何を見せるかを先に絞る
まず決めたいのは AI に何をやらせたいか より 何なら見せても安全か です。
最初から更新系ツールまで公開すると、便利さより先に事故ポイントが増えます。
最初の一歩としては、次が無難です。
- 読み取り専用のリソースを1つ作る
- 破壊的でない検索ツールを1つ作る
- 定型のプロンプトを1つ用意する
2. 入出力の形を決める
ツールなら、どんな引数を受けて、どんな結果を返すかをはっきりさせます。
ここが曖昧だと、AI 側が使いにくくなります。
実務では、引数名だけ見れば何を入れるか分かる くらいまで単純化した方が安定しやすいです。
複雑な1ツールを作るより、役割を絞った複数ツールの方が保守しやすいことも多いです。
3. ログ出力の場所を間違えない
これはかなり重要です。
stdio 接続では、stdout に余計なログを出すと JSON-RPC の通信が壊れます。
なんとなく console.log を置いたら動かなくなった というのは、MCPサーバー開発でかなり起こりやすいです。
標準出力にはプロトコルのメッセージだけを流し、ログは stderr 側へ分ける意識が必要です。
4. 公開前に権限を見直す
リモート公開するなら、そのツールは本当に誰でも叩けてよいのか を必ず見ます。
社内利用でも、読み取り専用で足りるなら更新系を混ぜない方が安全です。
実務で使われやすい場面
MCPサーバー は、派手な自動化より AI に必要な入口を揃える ところで効きます。
たとえば次のような場面です。
開発補助
リポジトリ検索、Issue 参照、ドキュメント読み取りを AI へ渡して調査を速くする。
社内ナレッジ検索
手順書や設計書をリソースとして見せ、更新系は出さずに読むだけで使う。
限定的な業務操作
申請作成や情報取得のように、範囲を絞ったツールだけ公開して人の確認を挟む。
このとき大事なのは、AI を何でもできる管理者にしない ことです。
便利さより先に、境界の分かりやすさを優先した方が長く運用しやすいです。
よくある失敗
強い権限をまとめて渡してしまう
便利そうだからと更新・削除まで同時に公開すると、事故時の影響が一気に大きくなります。
最初は検索や参照から始め、更新系は承認フローつきで後から追加する方が現実的です。
サーバーの役割が大きすぎる
1つの MCPサーバー に何でも詰め込むと、責任範囲が曖昧になります。
ファイル参照用 チケット操作用 社内API参照用 のように分けた方が理解しやすいです。
古い実装例をそのまま使う
MCP まわりは変化が早めです。
古い記事やサンプルだけを見るのではなく、公式仕様日付や公式 SDK の現行 README を先に見た方が安全です。
初心者が最初に触るなら
最初の1本としておすすめなのは、ローカルで動く読み取り中心の stdio サーバー です。
たとえば、特定フォルダのファイル一覧を返す、ドキュメントを読む、簡単な検索をする、くらいから始めると入りやすいです。
いきなりリモート公開や認証つきの HTTP サーバーへ行くと、MCP そのものより Web サーバー運用で詰まりやすくなります。
まずはローカルで サーバーが何を公開し、クライアントがどう呼ぶか を体でつかむのが近道です。
まとめ
MCPサーバー は、AI へツールやデータを公開する役を持つ、MCP の中核部分です。
公開できる要素は MCPツール、MCPリソース、MCPプロンプト で、接続方式としては stdio と Streamable HTTP を使い分けます。
実務では、便利さだけでなく 公開範囲を絞る ログ出力を壊さない 認証を後回しにしない がかなり大事です。
初心者のうちは、まずローカルの小さなサーバーを1本作って、責任範囲を小さく保つところから始めるのがおすすめです。
参考情報
- Model Context Protocol: Architecture Overview
- Model Context Protocol: Quickstart for Server Developers
- modelcontextprotocol/typescript-sdk: GitHub
- modelcontextprotocol/python-sdk: GitHub