インストール
npx @modelcontextprotocol/inspector誰向けか
モデルが設計の良いツール経由で外部 API やサービスを呼べるよう、高品質な MCP（Model Context Protocol）サーバーを作りたいときに mcp-builder を使う。言語は Python（FastMCP）または Node/TypeScript（MCP SDK）でよい。構築ガイドであり、指名されていないサーバーを代わりにホストするものではない。
より適切な前提は、いきなりインタフェースを書かず、先に深い調査と計画をするつもりであること。資料は TypeScript を、SDK サポートが良く、複数の実行環境（例えば MCPB）での互換性が良い選択として書いている。資料はエージェント製品名簿もリポジトリのインストールパスも出していない。公式ガイドページは
https://raw.githubusercontent.com/anthropics/skills/main/skills/mcp-builder/SKILL.md
3 分で最初の試行を終える
この説明は skill インストールコマンドを出していない。最初にパスを作らない。推奨経路は第 1 段階から始める：Deep Research and Planning。高品質な MCP サーバーには 4 つの主要段階がある。抜粋が完全に書いているのは第 1 段階の見出しだけなので、最初は計画だけ行い、サーバープロセスは書かない。
前提：つなぎたい外部 API またはサービスがすでにあります。低リスクな動作：そのサービスのどのクエリが読み取り専用でどれがデータを変えるかを列挙し、リモートは Streamable HTTP を使うと決める。概要はローカルに stdio も使えると述べるが、抜粋はリモートの Streamable HTTP だけを書いている。最初から stdio 引数が書き終わっていると思わない。
成功の合図：1 枚で「モデルにどのツールを渡し、入力にどんな制約を使うか」を言い切れること。先に npm init で未計画のプロジェクトを始めない。計画が確認できてから実装に入る。TypeScript 側は入力 schema に Zod を使える。フィールドには制約と明確な説明が必要で、フィールド説明に例を入れる。ファイルを書く前にディレクトリを確認する。
利用例
例 1：推奨 TypeScript スタックでリモートサーバーを計画する。MCP SDK を選び、転送は Streamable HTTP、入力は Zod、説明に制約と例を入れる。概要は outputSchema/structuredContent や readOnlyHint、destructiveHint などの注釈にも触れるが、抜粋はこれらのフィールドの完全な例を書いていない。この例の完了基準は、計画で読み取り専用ツールとデータを変えるツールを分けたことであり、全注釈を埋め終わったことではない。同時に Python 一式を「主経路」として立てない。Python FastMCP と Pydantic は並列の選択肢であり、二重書きは必須ではない。
例 2：実装のあとコンパイルと検査をする。TypeScript 経路は先に npm run build でコンパイルできることを確認し、続けて MCP Inspector：npx @modelcontextprotocol/inspector。Inspector は検査画面を開くので副作用がある。測る対象が今構築したローカルまたはリモートサーバーだと確認してから実行する。完了基準は build が通り、指定したサービスに Inspector がつながること。抜粋は Inspector の全フラグを書いていないので、接続パラメータを作らない。
利用上の境界
4 つの主要段階は深い調査と計画から始まる。後続を概要は実装してから検査・テストと要約するが、残りの段階見出しは抜粋で展開されていない。リモート転送は Streamable HTTP と書いてある。入力 schema は Zod または Pydantic。TypeScript の確認コマンドは npm run build と公式 Inspector。
リポジトリ内のインストールパスを作らない。資料はクライアント一覧も、計画を飛ばして直接公開する方法も書いていない。ここに書いた段階、言語選択肢、確認コマンドを超える範囲は、この説明の対象外である。