MCP 設定ビルダー

stdio・HTTP・SSE の MCP サーバー設定と、対応するコマンドラインを生成します。

URL・トークン・ローカルパスは端末に残ります。設定はブラウザー内で組み立てられ、送信されません。

そのサーバー用のツールを定義する

MCP サーバー設定 について

MCP サーバーの設定は小さな JSON ですが、失敗の仕方が容赦ありません。キーを一つ間違えてもエラーは出ず、サーバーがただ現れないだけです。トランスポートごとに必要な形が違い——ローカルならコマンドと引数、リモートなら URL とたいていヘッダー——混ぜると、完成して見えるのに何もしないファイルができます。このビルダーは選んだトランスポートが実際に使う項目だけを尋ね、もう一方の項目が埋まっていれば警告し、そして現場でおそらく最も多い間違いを指摘します。リポジトリに入るファイルに、生きた認証情報を書いてしまうことです。設定ファイルと、対応する一行コマンドの両方を出力します。

機能

• 選んだトランスポートが使う項目だけ
• もう一方のトランスポートの項目が埋まっている場合に警告
• 本物らしい秘密が書かれていれば指摘（プレースホルダーは指摘しません）
• リモートへの平文 HTTP に警告、localhost には沈黙
• コマンド欄に引数が紛れ込んでいるのを検出
• 環境変数とヘッダーを編集可能な組で入力
• プロジェクト用ファイルとデスクトップアプリ用設定の両方を出力
• 正しくクォートされた等価コマンド

MCP サーバー設定 の使い方

1. サーバー名を決めます — ツールの名前空間になります
2. 使うトランスポートを選びます
3. コマンドと引数、または URL とヘッダーを埋めます
4. JSON を設定にコピーするか、コマンドを実行します

例

入力

"command": "npx -y some-server"

出力

Warning: looked up as a single executable with that name

最初の語がコマンドで、残りはすべて引数です。

よくあるエラーとトラブルシューティング

• サーバーがまったく現れない。 — たいていは形の取り違えです。url を持つ stdio 設定か、command を持つリモート設定。どちらもここで指摘します。単体ではエラーにならないからです。
• コマンドが見つからない。 — 引数は分けて書きます。コマンド欄に npx、残りを引数一覧に。空白を含むコマンドは、その名前の単一の実行ファイルとして探されます。
• 自分の環境では動くのに他の人では動かない。 — 引数に自分のマシンの絶対パスが入っているか、自分の環境にしかない認証情報が要るかのどちらかです。
• 設定ファイルにトークンを書いてしまった。 — 環境変数を参照してください。本物らしい秘密はここで指摘します。設定ファイルはリポジトリに入るからです。

よくある質問

どのトランスポートを使うべきですか。

ローカルで動かすものはすべて stdio です。クライアントがプロセスとして起動し、標準入出力で会話します。リモートのサーバーには HTTP。SSE は HTTP が主流になる前に書かれたサーバーのために残っています。

設定ファイルはどこに置きますか。

プロジェクト用はリポジトリに置いてチーム全員が同じサーバーを使えます。デスクトップアプリはどこでも使いたいサーバー用に独自の設定を持ちます。両方の形を出力し、パスも表示します。

トークンをファイルの外に置くには。

値ではなく環境変数への参照として書いてください。ここでの点検は、値が本物の認証情報らしいか、プレースホルダーらしいかを見て、前者だけを指摘します。

ファイルとコマンド、どちらを使いますか。

どちらも同じことをします。プロジェクトと一緒に管理すべきならファイル、試すだけならコマンドのほうが速いでしょう。どちらも同じ入力から作られます。

サーバー名はなぜ重要ですか。

設定が保存されるキーであり、そのツールの名前空間でもあります。二つのサーバーで共有できず、改名するとツールの参照の仕方が全体で変わります。

関連ツール

• MCP ツールスキーマ — ツールを定義し、strict モードを検証した JSON Schema を得ます。
• ツールスキーマ検証 — 定義を貼り付け、拒否される理由や誤呼び出しの原因を調べます。
• フックビルダー — settings.json のフックを作り、発火しないマッチャーを見つけます。
• 権限ルールテスター — 許可・確認・拒否のルールを実際のコマンドで試します。
• プラグインマニフェスト — plugin.json を生成し、前提となるフォルダ構成を確認します。
• サブエージェントビルダー — ツールとモデルを指定してサブエージェント定義ファイルを作ります。

AI・エージェントの他のツール

• スキルビルダー — SKILL.md を作成し、frontmatter を入力しながら検証します。
• スキルリンター — SKILL.md を貼り付け、タスクに一致しない理由を確かめます。
• サブエージェントビルダー — ツールとモデルを指定してサブエージェント定義ファイルを作ります。
• スラッシュコマンドビルダー — 引数とツール許可リストを備えた独自コマンドを作ります。
• プロジェクト指示ビルダー — 毎リクエストの費用に見合う CLAUDE.md を書きます。
• プラグインマニフェスト — plugin.json を生成し、前提となるフォルダ構成を確認します。
• フックビルダー — settings.json のフックを作り、発火しないマッチャーを見つけます。
• 権限ルールテスター — 許可・確認・拒否のルールを実際のコマンドで試します。
• MCP ツールスキーマ — ツールを定義し、strict モードを検証した JSON Schema を得ます。
• ツールスキーマ検証 — 定義を貼り付け、拒否される理由や誤呼び出しの原因を調べます。
• プロンプトテンプレート展開 — 一つのプロンプトを行の表に展開し、欠けている値を確認します。
• システムプロンプトリンター — 矛盾、効かない指示、未置換のプレースホルダーを見つけます。
• プロンプト差分 — 二つの版を単語単位で比較し、トークン差も表示します。
• Few-shot 例ビルダー — 入出力の組をタグ付き、JSON、会話形式の例に変換します。
• XML プロンプト構成 — 内容が外に漏れないタグでプロンプトの各節を囲みます。
• JSONL ビューア・検証 — JSONL ファイルを行単位で読み、絞り込み、検証します。
• 会話ログ変換 — メッセージ配列を読みやすい記録に変換し、元にも戻します。
• 学習データ検証 — 学習を途中で止めるエラーがないか chat 形式の JSONL を調べます。
• SSE ストリームビューア — 生のストリーミング応答から本文、ツール呼び出し、使用量を取り出します。
• コンテキストウィンドウ設計 — ウィンドウをプロンプト、ツール、履歴、応答に配分します。
• プロンプトキャッシュ設計 — キャッシュできる接頭辞が最長になるようブロックを並べ替えます。
• テキスト分割 — 実際の切れ目で分かれる重なり付きのチャンクに文書を分けます。
• エージェントループ費用 — 再送される履歴とキャッシュを含めてターンごとに費用を見積もります。
• バッチリクエストビルダー — 行の表をバッチ処理に変換し、各リクエストに一意の ID を付けます。

AI・エージェントのツールをすべて見る · すべてのツール