10秒でいうと
SDKを使えば、関数に印を1つ付けるだけでツールになります。
難しいのはコードではなく、説明文をどう書くかのほうです。
既存のサーバーが無いもの——社内の在庫システム、独自の基幹システム、部署だけで使っているデータベース——は自分で作ります。
思っているより簡単です。
最小のサーバー
Python向けのSDKを使うと、こうなります。
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("inventory")
@mcp.tool()
async def get_stock(item_code: str) -> str:
"""商品の在庫数を調べる。
Args:
item_code: 商品コード(例:A-1024)
"""
# ここで社内システムに問い合わせる
return f"{item_code} の在庫は 42 個です"
if __name__ == "__main__":
mcp.run(transport="stdio")
これで動きます。@mcp.tool() を付けた関数が、そのままClaudeから呼べる道具になります。
引数の型注釈と、docstringが、そのまま道具の説明になります。別に定義ファイルを書く必要はありません。SDKが tools/list の応答を組み立ててくれます。
つなぐときは stdio です(No.46)。
claude mcp add --transport stdio inventory -- python /path/to/server.py
難しいのは説明文のほう
コードより、docstringの書き方で精度が決まります。No.20で書いた話がそのまま効きます。
悪い例。
@mcp.tool()
async def get_stock(item_code: str) -> str:
"""在庫を調べる"""
良い例。
@mcp.tool()
async def get_stock(item_code: str) -> str:
"""指定した商品コードの現在庫数を、本社倉庫について調べる。
支店の在庫は含まない。商品コードが分からない場合は
search_item を先に使うこと。
Args:
item_code: 商品コード。「A-1024」の形式。ハイフンを含む
"""
違いは3つです。何を返さないかを書く(支店は含まない)。先に使うべき道具を書く(コードが不明なら検索から)。引数の形式を具体的に書く(ハイフンを含む)。
3つ目が特に効きます。No.20で書いたとおり、引数が足りないとClaudeは推測で埋めることがあります。形式を明示すれば、その推測が減ります。
何を出すか
MCPが出せるのは3つでした(No.45)。自作するとき、実際に使うのはほぼツールです。
ただし、リソースが効く場面が1つあります。スキーマや一覧のように、毎回変わらないがサイズが大きいもの。ツールで毎回取りに行くより、リソースとして置いておくほうが素直です。
読み取り専用から始める
No.47で書いた基準を、作る側でも守ってください。
最初は読む道具だけ作る。在庫を調べる、注文を検索する、状況を確認する。書き込みは、読み取りが安定してから足します。
書き込む道具を作るときは、取り消せる形にするか、確認の一手を挟むか、どちらかを設計に入れてください。第3章のNo.19で書いた「元に戻せない操作は人が最後のボタンを押す」が、ここでは自分の設計責任になります。
試す
作っている最中は、MCP Inspectorという公式の開発ツールが使えます。Claudeにつなぐ前に、道具の一覧と応答を直接確認できます。
つないだあとは、claude mcp list で状態を見て、/mcp で有効か確かめます(No.46)。動かないときの切り分けは、この順が速い。
- Inspectorで、サーバー単体が答えるか
claude mcp listで、接続できているか/contextで、道具が読み込まれているか- 呼ばれないなら、説明文を見直す
4番目に行き着くことが多い、というのが実感です。
やってみよう:説明文を採点させる(5分)
つなぎたい社内システムを1つ想定してください。実装は不要です。
プロンプト
“`
MCPサーバーの道具の説明文(docstring)を設計します。道具:(何をする道具か1行で)
次を含めた説明文を書いてください。
・何をする道具か
・何を返さないか、扱わない範囲
・先に使うべき別の道具があるか
・引数の具体的な形式そのあと、その説明文だと誤って呼ばれそうな場面を3つ挙げてください。
“`期待される結果:説明文と、その弱点が3つ返る。
うまくいかないとき:弱点が出ないなら「意地悪な使われ方を想定して」と足してください。正しく使われる場面より、誤って呼ばれる場面を想像して書くほうが良くなります。
つまずきポイント
最初から機能を盛る。道具を10個作ると、選び間違えが起きます。1つ作って、動かして、それから足す。
説明文を後回しにする。動くコードより、説明文のほうが結果を左右します。
社内システムに書き込む道具を先に作る。読むだけから。
エラーをそのまま返さない。例外が飛ぶと、Claudeは何が起きたか分かりません。在庫システムに接続できませんでした、のように読める文字列で返してください。
まとめ
- SDKを使えば関数に印を1つでツールになる
- 難しいのはコードではなく説明文。返さないもの、引数の形式まで書く
- 読む道具から作る。書き込みは安定してから
- 呼ばれないときは、たいてい説明文の問題
次に読む
※本記事の情報は 2026年8月時点のものです。