Claude CodeのMCPサーバーを見直す方法｜棚卸しと削除の判断基準

Claude CodeにMCPサーバーを足していくと、しばらくして「このサーバーは何のために入れたのか」「どこに設定が書いてあるのか」が分からなくなります。追加の手順は前の記事で整理しました。この記事は、追加済みのサーバーを洗い出し、使うもの・止めるもの・消すものに分けるまでの手順を扱います。

結論から言うと、見直しは次の順に進めると迷いません。まず定義が置かれている場所を洗い出し、次に同名や同じ接続先の重複を整理し、そのうえで止めるか消すかを決め、最後に残すサーバーの提供元と権限を確認します。同じ順で、クローンしたリポジトリの.mcp.json、claude.aiのコネクタ、プラグイン由来のサーバー、組織の管理設定まで確認します。

根拠にしたのは、2026年10月10日に確認した公式ドキュメントの次の6ページです。MCP、権限、セキュリティ、設定リファレンス、CLIリファレンス、管理されたMCP設定です。公式ドキュメント全体を読み切ったわけではなく、この6ページの記載の範囲で書いています。バージョン番号は、公式が「以降」「より前」と書いている箇所だけを、そのまま引用しています。

MCPサーバーの見直しとは何か｜追加したあとに残る3つの負担

MCPサーバーの見直しとは、Claude Codeに接続済みのサーバーを洗い出し、使うもの・止めるもの・消すものに分けたうえで、残すサーバーの接続先と権限を確認し直す作業のことです。

追加した直後は、そのサーバーを使う目的がはっきりしています。時間が経つと、次の3つの負担が残ります。1つ目は、定義が複数の場所に分かれて見えにくくなること。2つ目は、接続先を信頼し続けてよいかの確認が後回しになること。3つ目は、使っていないサーバーの名前や指示が毎回の会話に載り続けることです。

1つ目について、公式のセキュリティのページは、プロジェクトの.mcp.jsonを確認しても、セッションが読み込みうるサーバーのすべては分からないと説明しています。ほかのスコープのサーバーやclaude.aiのコネクタはリポジトリの外で設定され、プラグインもサーバーを追加できるためです(Security)。つまり、1つのファイルを見るだけでは棚卸しになりません。

3つ目について、公式のツール検索の説明では、既定でセッション開始時に読み込まれるのはツール名とサーバーの指示だけで、ツールの定義は必要になるまで遅らされます(Connect Claude Code to tools via MCP)。そのため、サーバーを増やしても影響は小さいとされていますが、使わないサーバーの名前と指示が読み込まれ続けることに変わりはありません。会話全体の使用量を見たいときは、使用量とコストの確認方法で見方を整理しています。

なお、サーバーの追加コマンドやスコープの選び方はMCPサーバーを追加する方法で、MCPそのものの仕組みはMCPとはの解説で扱っています。この記事は、それらを済ませたあとに読む位置づけです。

サーバーの定義が置かれる場所｜スコープ・プラグイン・コネクタ・組織設定

サーバーの定義の場所とは、あるMCPサーバーの設定がどのファイルや仕組みに保存され、誰に共有され、どの操作で止められるかを決めている保管先のことです。

見直しの最初の作業は、定義がどこに置かれうるかを知ることです。公式は、サーバーの設定をlocal・project・userの3つのスコープに分けています。localは既定で、追加したプロジェクトでだけ読み込まれ、自分専用で、~/.claude.jsonに保存されます。projectはプロジェクト直下の.mcp.jsonに保存され、バージョン管理でチームに共有されます。userは~/.claude.jsonに保存され、自分の全プロジェクトで使えます(MCP installation scopes)。

この3つ以外に、プラグインが持ち込むサーバー、claude.aiのコネクタ、組織が管理設定で提供するサーバーがあります。次の表は、公式の記載をもとに、見直しの観点で並べ直したものです。

種類	定義の場所	共有の範囲	止め方・消し方
local	~/.claude.jsonのプロジェクトごとの欄	自分だけ	claude mcp remove、または/mcpでオフ
project	プロジェクト直下の.mcp.json	バージョン管理を通じてチーム	ファイルから削除、またはdisabledMcpjsonServersで拒否
user	~/.claude.json	自分の全プロジェクト	claude mcp removeに--scopeを付ける、または/mcpでオフ
プラグイン	プラグインの設定	プラグインを有効にした環境	プラグインをアンインストール、または/mcpでオフ
claude.aiのコネクタ	claude.ai側の設定	claude.aiのアカウントや組織	disableClaudeAiConnectors、/mcpのオフ、deniedMcpServers
組織の管理設定	管理者が配る設定ファイル	組織の利用者	管理者が変更。利用者は自分のdeniedMcpServersで自分の分を止められる

表の最後の行について、公式の管理設定のページには、利用者自身のdeniedMcpServersが設定から統合されるため、組織が配ったサーバーを自分用に止められるという記載があります(Managed MCP configuration)。また、プラグインのサーバーは/mcpのコマンドで追加や削除をするのではなく、プラグインのインストールとアンインストールで増減します(Plugin-provided MCP servers)。プラグイン自体の扱いはプラグインの使い方にまとめています。

仮の例として、「同じ名前のサーバーが出てくるが、どのファイルを直せばよいか分からない」という状況を考えます。この表のどの行にそのサーバーがいるかを先に特定できれば、直す場所は1か所に絞れます。以降の手順は、この特定を行うための作業です。

棚卸しの手順1｜list・get・/mcpで現状を一覧にする

棚卸しの手順1とは、claude mcp list・claude mcp get・/mcpの3つで、サーバーの名前・接続状態・設定警告を一度に書き出す作業のことです。

公式が示す管理コマンドは、一覧のclaude mcp list、1件の詳細のclaude mcp get <name>、削除のclaude mcp remove <name>、セッション内の確認の/mcpです(Managing your servers)。棚卸しでは、まず見直したいフォルダで次の2つを実行して結果を控えます。

claude mcp list
claude mcp get <name>

localスコープのサーバーは追加したプロジェクトでだけ読み込まれるので、見直しはプロジェクトのフォルダごとに行うと取りこぼしが減ります。この点は編集部の運用上の提案で、公式の手順ではありません。

一覧には、サーバーごとに接続状態が付きます。公式は✔ Connected、! Needs authentication、✘ Failed to connectを例に挙げています。接続を試みずに設定の判断だけを示す状態として、⏸ Pending approval、✘ Rejected、⊘ Disabled for this projectもあります。それぞれの意味と次の操作は、追加手順の記事の管理の節に表で載せているので、ここでは棚卸しの視点に絞ります。つまり、Connectedなら「使っているか」を、それ以外なら「直すか外すか」を、次の節以降で判断します。

セッションの中では/mcpが役に立ちます。公式によると、/mcpのパネルは接続済みのサーバーごとにツール数を表示し、ツールの機能を宣言しているのにツールを1つも公開していないサーバーに印を付けます(Tool availability)。ツールを1つも公開していないサーバーは、棚卸しで最初に目を向ける対象になります。

設定警告は棚卸しの手がかりになる

公式は、設定の問題に対してClaude Codeが警告を出す場合を挙げています。claude mcp listと/mcpに出るので、棚卸しの途中で警告が出たら、その場で対処を決めておくと後戻りが減ります(Configuration warnings)。

警告の種類	公式が説明する内容	見直しでの対応
見えない空白	設定値の前後に目に見えない空白がある。トークンを貼り付けた際の改行が原因になりやすい。Claude Codeは空白を削らず、書かれたとおりに使う	該当の項目を開いて空白を取り除く
複数スコープの同名	同じ名前を別の接続先で複数のスコープに定義すると衝突の警告が出る。OAuthのサインインは接続先ごとに保存される	残す接続先を決め、ほかをclaude mcp remove <name> --scope <scope>で削除する
予約名	組み込みサーバーの名前は予約されており、同じ名前の定義は読み込み時に読み飛ばされる	別の名前に付け替える
未設定の環境変数	${VAR}が未設定で既定値もないと警告が出る。設定は読み込まれ、${VAR}の文字がそのまま使われる	変数を設定するか、${VAR:-default}の形にする

この表で注意したいのは、予約名と未設定の環境変数です。どちらも「エラーで止まる」のではなく、読み飛ばされるか、文字のまま使われます。一覧に名前が出ていても期待どおりに動いていない場合は、まず警告の有無を確かめます。

棚卸しの手順2｜同名・同じ接続先の重複を整理する

重複の整理とは、同じサーバーが複数のスコープやプラグイン、コネクタで定義されているときに、どの定義が実際に使われるかを確かめ、不要な定義を取り除く作業のことです。

公式によると、同じサーバーが複数の場所で定義されている場合、Claude Codeは優先度が上の定義を使って1回だけ接続します。そのサーバーの項目全体が使われ、スコープをまたいで項目が混ぜ合わされることはありません。優先順位は、1番目がlocalスコープ、2番目がprojectスコープ、3番目がuserスコープ、4番目がプラグインのサーバー、5番目がclaude.aiのコネクタです(Scope hierarchy and precedence)。

重複の判定にも決まりがあります。3つのスコープの間では名前で照合し、プラグインとコネクタは接続先で照合します。つまり、プラグインのサーバーが、すでに有効な別のサーバーと同じURLやコマンドを指していれば、重複として扱われます。URLの表記は、スキームやホストの大文字小文字、スキームの既定ポート、末尾のスラッシュだけが違う場合に同じ接続先とみなされ、パスやクエリ、既定でないポートが違えば別のサーバーになります(Scope hierarchy and precedence)。

ここから、見直しの実務で役立つ読み方が出てきます。優先度が上の定義が使われるため、低い側の定義を消しても動作が変わらない場合があります。逆に、高い側の定義を消すと、それまで隠れていた低い側の定義が表に出ます。消す順番を間違えると、意図しない接続先に切り替わりかねません。

仮の例を挙げます。userスコープのdocs-searchはサービスAの接続先を、プロジェクトの.mcp.jsonのdocs-searchはサービスBの接続先を指しているとします。このプロジェクトでは優先順位の高いprojectの定義が使われ、サービスBに接続します。別のプロジェクトではuserの定義が使われるため、同じ名前で接続先が変わります。OAuthのサインインは接続先ごとに保存されるので、片方のプロジェクトで認証しても、もう片方では別に認証が要ります。

この状態は、次の順で整理します。

1. claude mcp listで衝突の警告を確認する。
2. claude mcp get docs-searchで、いま使われている定義の接続先を確かめる。
3. 残す接続先を決め、不要な側をclaude mcp remove docs-search --scope userのように、スコープを指定して削除する。
4. もう一度claude mcp listを実行し、警告が消えて接続状態が期待どおりかを確かめる。

公式は、同名の衝突への対処として、残したい接続先を決めてほかをclaude mcp remove <name> --scope <scope>で削除することを案内しています(Configuration warnings)。チームで共有している.mcp.json側の定義を消す場合は、自分の環境だけの変更ではなくなるため、チームへの周知が先です。

棚卸しの手順3｜止める・消す・認証を外すを使い分ける

止める・消す・認証を外すの使い分けとは、サーバーの設定を残すか、設定ごと取り除くか、保存済みのOAuth認証情報だけを消すかを、再び使う見込みに応じて選ぶ判断のことです。

見直しで迷いやすいのが、止めるべきか消すべきかです。公式が説明する操作の結果は次のとおりです(MCP、CLI reference)。

やりたいこと	操作	公式が説明する結果	向く場面
しばらく使わない	/mcpでサーバーをオフにする	設定を失わずに、Claude Codeが接続しなくなる。/mcpには無効として残る	また使う見込みがあるとき
使わないと決めた	claude mcp remove <name>	リモートサーバーでは、保存していたOAuthトークンとクライアント登録も削除される	代わりのサーバーがある、または用途が終わったとき
認証だけ外したい	claude mcp logout <name>、または/mcpのメニューにあるClear authentication	保存済みのOAuth認証情報を消す	アカウントを切り替えるとき、アクセスを取り消したいとき
プラグインのサーバーを外す	プラグインのアンインストール	プラグインのサーバーは、プラグインの導入と削除で増減する	プラグインごと不要なとき

オフにした場合の記録先も、見直しでは役に立ちます。公式によると、オフの選択はプロジェクトごとに~/.claude.jsonへ記録され、記録先は2つのリストに分かれます。disabledMcpServersは、利用者が設定したサーバー、プラグインのサーバー、組織が管理設定で提供するサーバー、Claude Codeが自分で取得するclaude.aiのコネクタ、既定でオンの組み込みサーバーの除外リストです。enabledMcpServersは、computer-useのように既定でオフの組み込みサーバーを有効にするためのリストです。Claude Codeは1つのサーバーにつきどちらか一方のリストだけを見るので、取り違えた側に書いても効果はありません(Disable a server without removing it)。

止めるか消すかは、次の基準で決められます。これらは公式の基準ではなく、編集部が棚卸しで使うことを勧める判断軸です。

• 再び使う予定があるか: 予定があるなら止める。予定がなければ消す。
• 再設定の手間が大きいか: 環境変数や認証の準備に手間がかかるなら、消す前に止めて様子を見る。
• 代わりの手段があるか: 別のサーバーやコマンドで足りるなら消す。
• 共有定義か自分専用か: .mcp.jsonの定義は、自分だけの判断で消さずにチームと相談する。

仮の例として、ある検証用のサーバーを2週間ほど使っていないとします。再び使う予定が決まっていないなら、まず/mcpでオフにして、次の見直しまで様子を見る進め方があります。日数は一例です。オフにしても困らなかったと確認できてからclaude mcp removeで消せば、消してから後悔するリスクを抑えられます。

信頼できるサーバーかを確かめる観点｜提供元・接続先・渡す権限

サーバーの信頼確認とは、MCPサーバーの提供元、接続先、動く場所、渡す認証情報の範囲を確かめ、そのサーバーに自分の作業環境へのアクセスを任せてよいかを判断することです。

公式のMCPのページは、サーバーを接続する前に信頼できるかを確認するよう警告しています。外部の内容を取得するサーバーは、プロンプトインジェクションのリスクにさらされる場合がある、という説明です(Find and build MCP servers)。プロンプトインジェクションとは、AIの指示を上書きするような文章を外部の内容に紛れ込ませる手口のことで、公式のセキュリティのページに概要があります。

セキュリティのページでは、自分でMCPサーバーを書くか、信頼できる提供元のサーバーを使うことを勧めています。AnthropicはAnthropic Directoryに載せるコネクタを掲載基準に照らして審査しますが、MCPサーバーのセキュリティ監査や管理は行わない、とも書かれています(MCP security)。Directoryに載っていることは、安全の保証とは別の話だと読めます。

見直しの場面では、サーバーの種類によって見る点が変わります。公式は、設定の元になる情報を「URL」と「起動コマンド」に分けています。URLならリモートのサーバーで、npx -y @example/mcp-serverのような起動コマンドなら、そのサーバーは自分のマシン上で動きます(Add a server from setup instructions written for another client)。

種類	公式の説明	見直しで確認すること(編集部の観点)
リモート(URL)	サーバーはリモートにある	接続先のドメインの運営者、サインイン時に求められる権限の範囲
ローカル(起動コマンド)	サーバーは自分のマシン上で動く	コマンドの配布元、更新の止まっているパッケージではないか
claude.aiのコネクタ	claude.aiで追加したサーバーが自動で使える	自分や組織が追加したものか、不要になっていないか

権限の範囲については、公式にoauth.scopesの設定があります。認可の流れでClaude Codeが要求するスコープを固定する方法で、認可サーバーが広いスコープを提示する場合に、承認済みの範囲に絞るために使えると説明されています(Restrict OAuth scopes)。サーバーに渡す権限を後から絞りたいときの選択肢です。

以上の公式の説明を踏まえて、編集部が棚卸しで確認する観点を挙げます。公式のチェックリストではありません。

1. 誰が運営しているサーバーか、説明できるか。
2. どの接続先やコマンドが動くのか、claude mcp getで確認できているか。
3. 渡している認証情報は、使う機能に対して広すぎないか。
4. 外部のウェブ上の内容を取り込むサーバーか。取り込む場合、その内容に紛れた指示で動作が変わる可能性を踏まえて、権限の設定をしているか。

クローンしたリポジトリの.mcp.jsonを扱うときの確認

クローンしたリポジトリの.mcp.jsonの確認とは、他人が書いた設定ファイルが自分の環境で勝手にサーバーを動かさないよう、承認の仕組みと起動方法ごとの挙動を把握しておくことです。

projectスコープのサーバーは.mcp.jsonに書かれ、リポジトリごと配られます。そのため、クローンした直後の扱いが重要です。公式によると、対話セッションでは.mcp.jsonのサーバーを使う前に承認を求められ、承認の選択をやり直したいときはclaude mcp reset-project-choicesを実行します(Project scope)。

公式は、v2.1.196以降のclaude mcp listとclaude mcp getについて、ワークスペースを信頼するまでは、リポジトリにコミットされていない設定ファイルの承認だけを読むと説明しています。リポジトリ自身が書いたenableAllProjectMcpServersやenabledMcpjsonServersは、信頼していないフォルダでは無視され、サーバーはPending approvalのままになります。クローンしたリポジトリが、自分のサーバーを自分で承認することはできません(Project server approvals and workspace trust)。

一方で、承認の確認が出ない起動方法があります。次の表は、公式の記載をまとめたものです。

起動の状況	.mcp.jsonのサーバーの扱い
対話セッション	承認のプロンプトが出る
親フォルダだけを信頼した状態	接続する前に確認される。リポジトリ自身の承認は数えられない
claude -pやSDK(フォルダを信頼したことがない)	承認の有無にかかわらず、確認なしで接続される。SDKはsettingSourcesにプロジェクト設定を含めた場合だけ読み込む
クラウドセッション	確認のプロンプトを出せず、確認なしで読み込まれる

この表の2行目と3行目は権限のページ、4行目はMCPのページの記載にもとづいています。claude -pの基本はヘッドレスモードの使い方に、クラウドセッションの条件はWeb版の使い方にまとめています。

自分が書いていないリポジトリでclaude -pを使う前に、公式は次の対策を挙げています(What runs before you trust a folder)。

• --setting-sources userを渡して、プロジェクトの設定ファイルと.mcp.jsonを読まない。
• --bareで起動して、プロジェクトの.mcp.jsonのサーバーなどを読まない。
• disabledMcpjsonServersに名前を登録して、すべての起動方法で.mcp.jsonのサーバーを拒否する。

公式のCLIリファレンスには、--strict-mcp-configもあります。--mcp-configで渡したサーバーだけを使い、ほかのMCP設定を無視するオプションです(CLI reference)。拒否の設定は、承認ダイアログでサーバーを拒否すると.claude/settings.local.jsonに書かれ、enabledMcpjsonServersとenableAllProjectMcpServersよりも優先されます(disabledMcpjsonServers)。

棚卸しでは、設定ファイルにenableAllProjectMcpServersが入っていないかも探します。公式の一覧では、このキーは.mcp.jsonのサーバーをすべてプロンプトなしで承認する設定と説明されています(Settings reference)。便利な反面、リポジトリを新しく開くたびに確認が出なくなるため、残す理由を説明できない場合は外す候補になります。

権限ルールでMCPツールの範囲を絞る

MCPツールの権限ルールとは、サーバー名とツール名を指定して、Claude Codeが呼び出せるMCPツールを許可・確認・拒否のどれにするかを決める設定のことです。

サーバーを残すと決めたあとは、使えるツールを必要な範囲に絞る見直しもできます。公式の権限のページによると、MCPのルールは、Claude Codeで設定したサーバー名の後ろに、必要ならそのサーバーのツール名を続けて書きます。mcp__puppeteerはそのサーバーのツールすべてに、mcp__puppeteer__*も同様にすべてのツールに、mcp__puppeteer__puppeteer_navigateはそのツール1つに当てはまります(Permissions: MCP)。

拒否と確認のルールは、ツール名の位置にワイルドカードを書けます。"mcp__*"を拒否に入れると、すべてのサーバーのMCPツールが使えなくなります。許可のルールは、ワイルドカードをmcp__<server>__という決まった接頭辞の後ろにだけ書けます。サーバー名の部分にワイルドカードを含む許可ルールは読み飛ばされ、何も自動承認しません(Tool name wildcards)。

書き方の注意点が1つあります。公式によると、設定ファイルを読み込むとき、括弧付きのmcp__ルールは読み飛ばされます。MCPツールの引数まで条件にしたい場合は、--disallowedToolsで拒否ルールを渡す方法が案内されています(Permissions)。

仮の例として、docs-searchという名前のサーバーのうち、読み取り系のツールだけを自動で許可し、書き込み系のツールは確認させたいとします。許可にはmcp__docs-search__get_*のような接頭辞付きの書き方を使い、確認させたいツールには個別のツール名で確認のルールを置く、という組み立てになります。ツール名は説明用に作った例で、実在のサーバーのものではありません。

権限の仕組みそのもの(許可・確認・拒否の優先順位、ルールの置き場所)は権限設定(permissions)の使い方で扱っています。MCPのツールをフックで監視したい場合の書き方は、フックの使い方の記事が入口になります。

claude.aiのコネクタとプラグイン由来のサーバーを見直す

コネクタとプラグイン由来のサーバーの見直しとは、自分でコマンドを打って追加していないのに読み込まれているMCPサーバーを見つけ、必要なものだけを残す作業のことです。

自分で追加した覚えのないサーバーが/mcpに出る原因の1つが、claude.aiのコネクタです。公式によると、claude.aiのアカウントでClaude Codeにログインしている場合、claude.aiに追加したMCPサーバーは自動でClaude Codeでも使えるようになります。チームプランとエンタープライズプランでは、サーバーを追加できるのは管理者だけです(Use MCP servers from claude.ai)。

コネクタが取得される条件にも決まりがあります。公式は、取得されるのは有効な認証方法がclaude.aiのサブスクリプションのログインである場合だけだと説明しています。ANTHROPIC_API_KEYなどを使っている場合や、Amazon Bedrockのようなサードパーティのプロバイダを使っている場合には、前にログインしていても読み込まれません。コネクタが見つからないときは/statusで認証方法を確認するよう案内されています(Use MCP servers from claude.ai)。

止める方法は目的で選びます。Claude Codeが取得するコネクタを止める設定は、どの設定スコープでもdisableClaudeAiConnectorsをtrueにします。現在のシェルだけなら、環境変数ENABLE_CLAUDEAI_MCP_SERVERSをfalseにして起動します。個別に止めるなら、deniedMcpServersに"claude.ai Slack"のような名前で登録します。現在のプロジェクトだけなら、/mcpのトグルで切り替えられます(Disable claude.ai connectors)。

ENABLE_CLAUDEAI_MCP_SERVERS=false claude

この設定が効く範囲には限りがあります。公式の表によると、これらの設定が働くのは、ターミナルやVS Code、JetBrains、Agent SDKのセッションのように、Claude Codeがコネクタを自分で取得する場合です。クラウドセッションやデスクトップアプリのローカルセッションでは、コネクタの届き方と制御の仕組みが違います(How connectors reach Claude Code)。自分の使う環境がどの行に当たるかを確認してから、設定を選びます。

プラグイン由来のサーバーは、プラグインを入れたときに自動で増えます。公式は、プラグインのサーバーを/mcpのコマンドで追加・削除するのではなく、プラグインの導入と削除で扱うと説明しています。/mcpでは、プラグイン由来であることが分かる表示が付きます。不要なプラグインを入れたままにしていると、そのサーバーも読み込まれ続けるため、棚卸しではプラグインの一覧も合わせて確認します(Plugin-provided MCP servers)。

接続できないサーバーを直すか外すかを判断する

接続できないサーバーの判断とは、Failed to connectやNeeds authenticationが出ているサーバーについて、自動再接続の仕組みを踏まえて、手動で直すか、設定ごと外すかを決めることです。

棚卸しで見つかる接続失敗のサーバーは、直す価値があるかを先に判断します。公式は、リモートサーバーが途中で切れた場合、Claude Codeが指数的な待ち時間を挟んで再接続すると説明しています。5回までで、1秒の待ち時間から始めて、毎回2倍にします。5回失敗するとサーバーは失敗とされ、サーバーが再認証を求めている場合は認証が必要とされます(Automatic reconnection)。

この記載から、待ち時間の合計を計算できます。待ち時間が1・2・4・8・16秒と倍になり、5回それぞれの直前に待つと読んだ場合の計算です。接続の試行そのものにかかる時間は含みません。

試行	直前の待ち時間	待ち時間の累計
1回目	1秒	1秒
2回目	2秒	3秒
3回目	4秒	7秒
4回目	8秒	15秒
5回目	16秒	31秒

この計算が示すのは、自動再接続が粘る時間はおおむね数十秒で、そこで失敗とされたサーバーは、手動での再試行や設定の見直しが必要な状態になるということです。公式の記載から導いた編集部の計算であり、実際の動作時間の保証ではありません。

再接続の対象にも違いがあります。公式は、HTTPやSSEのサーバーの最初の接続が、5xxの応答や接続拒否、タイムアウトのような一時的なエラーで失敗した場合に最大3回まで再試行すると説明しています。認証エラーや見つからないエラーは、設定の変更が必要なので再試行されません。stdioのサーバーはローカルのプロセスのため、自動では再接続されません(Automatic reconnection)。

手動で試すなら、失敗や認証待ちのサーバーをまとめて再試行する/mcp reconnect allがあります。公式によると、対話のターミナルでこれを使うにはv2.1.284以降が必要で、それより前のバージョンではMCP server "all" not foundと出ます。認証をやり直すなら、/mcpのパネル、またはシェルからclaude mcp login <name>を使います(Retry failed servers yourself)。

直すか外すかは、次のように分けられます。

• 原因が認証切れだけなら、再認証して残す。
• claude mcp get <name>のIssue:行にHTTPステータスやサーバーのエラー文が出ていて、設定の誤りと分かるなら、設定を直す。
• 使っていないうえに失敗が続くサーバーは、直さずにclaude mcp removeで外す。

公式によると、Failed to connectのときはclaude mcp listが失敗の詳細を状態の行に追記し、claude mcp getはIssue:行に表示します。資格情報に見える文字列は伏せられ、展開後のURLは含まれません(Server status detail)。

チームと組織で管理するときの進め方

チームと組織での管理とは、個人の棚卸しに加えて、共有の.mcp.jsonと管理設定を使い、承認済みのサーバーだけが利用者の環境で動く状態を保つ運用のことです。

個人の見直しでは、自分の判断で止めたり消したりできます。チームになると、誰かが追加したサーバーが全員の環境に載るため、変更の経路を決めておく必要があります。.mcp.jsonはバージョン管理に入れて共有するのが公式の案内なので、サーバーの追加や削除は、ほかの設定ファイルと同じように、レビューを通す運用が考えられます。これは編集部の提案です。

組織が利用者のサーバーを管理したい場合、公式の管理設定のページに複数のパターンが載っています。次の表は、その主なものです(Managed MCP configuration)。

パターン	公式が説明する内容	設定の入口
固定配布	全利用者が同じサーバーを受け取り、ほかを追加できない	サーバーを書いたmanaged-mcp.json
提供サーバー	リモートサーバーを配りつつ、利用者自身のサーバーも使える	管理設定のmanagedMcpServers
承認済みカタログ	承認済みの一覧を公開し、一覧外は遮断される	allowedMcpServersとallowManagedMcpServersOnly: true
拒否リストのみ	既知の問題のあるサーバーだけを遮断し、ほかは許可する	deniedMcpServers

この表はパターンの一部です。公式の一覧にはほかにも、MCPを無効にするパターンや、プラグインのサーバーだけを許可するパターンが載っています。公式は、Claude Codeにはユーザーが閲覧してインストールできる組み込みのMCPサーバー登録所はない、とも説明しています。承認済みカタログの方式を取るなら、承認済みの一覧とclaude mcp addのコマンドを、社内のWikiなど利用者が見つけやすい場所に置くよう案内されています(Managed MCP configuration)。

個人の利用でも、この考え方は役に立ちます。自分用の「承認済みサーバー一覧」を1枚持っておくと、見直しのたびに、一覧にないサーバーが入っていないかを照合するだけで済みます。

見直しの記録を残す｜仮の例つき棚卸しシート

棚卸しシートとは、サーバーごとに定義の場所、最後に使った時期、判断、実行した操作を1行で記録し、次回の見直しの出発点にする一覧表のことです。

ここまでの手順を、記録に落とし込みます。次の表は、仮の例として6つのサーバーを棚卸しした結果です。名前や状況はすべて説明用に作ったもので、実在のものではありません。

サーバー(仮)	定義の場所	最後に使った時期(仮)	判断	操作
docs-search	userとproject(接続先が違う)	先週	projectの定義を残す	userの定義をclaude mcp remove docs-search --scope userで削除
db-readonly	project(.mcp.json)	今週	残す	権限ルールで書き込み系ツールを確認にする
issue-tracker	local	1か月以上前	止める	/mcpでオフ
design-viewer	プラグイン	未使用	プラグインごと外す	プラグインをアンインストール
chat-connector	claude.aiのコネクタ	今月	このプロジェクトでは不要	/mcpのトグルでオフ
old-scraper	user	半年以上前、接続も失敗	消す	claude mcp remove old-scraper --scope user

この仮の例では、6つのサーバーのうち、そのまま残すのはdocs-searchとdb-readonlyの2つ、止めるのはissue-trackerとchat-connectorの2つ、消すのはdesign-viewerとold-scraperの2つです。そのまま残す2つも、重複の整理や権限の見直しという作業が伴います。「全部残す」「全部消す」という判断ではなく、1行ずつ根拠を残せる形にしておくのがこのシートの目的です。

シートの作り方は、次の流れが取りやすい形です。

1. 見直したいフォルダでclaude mcp listを実行し、名前と接続状態を転記する。
2. 各サーバーにclaude mcp getを実行し、接続先と定義の場所を書き足す。
3. 使った時期を、自分の記憶か作業の記録から埋める。
4. 判断と操作を書き、実行したら結果をclaude mcp listで確かめて日付を残す。

見直しの頻度は、利用の状況で決めます。サーバーを頻繁に試す時期は短めに、安定している時期は長めにします。頻度の決まりは公式にはなく、編集部の運用の提案です。会話が長くなってコンテキストが膨らむ悩みは別の手当てが要るため、/compactの使い方も併せて確認してください。

よくある質問(FAQ)

Q1. サーバーを止めるのと消すのは、どちらを選べばよいですか。

再び使う予定があるなら止め、予定がなければ消す、という考え方が基本です。公式によると、/mcpでオフにしても設定は失われません。claude mcp removeでリモートサーバーを削除すると、保存していたOAuthトークンとクライアント登録も削除されます(MCP)。

Q2. 削除したはずのサーバーが、また一覧に出てきます。

同じ名前が別のスコープに定義されている可能性があります。公式によると、同名のサーバーを複数のスコープに定義すると警告が出るので、claude mcp listで警告を確認し、claude mcp remove <name> --scope <scope>でスコープを指定して削除します。プラグインやclaude.aiのコネクタ経由で入っている場合は、それぞれの止め方で外します(Configuration warnings)。

Q3. .mcp.jsonの承認の選択をやり直せますか。

はい。公式によると、claude mcp reset-project-choicesを実行すると、承認の選択をリセットできます。リセット後に対話でclaudeを起動すると、再び承認を確認されます(Project scope)。

Q4. 組織で使えるMCPサーバーを制限できますか。

できます。公式の管理設定のページには、固定配布、提供サーバー、承認済みカタログ、拒否リストのみといったパターンが載っています。管理者がmanaged-mcp.jsonやallowedMcpServers、deniedMcpServersで設定します(Managed MCP configuration)。

Q5. サーバーが増えると、コンテキストを圧迫しますか。

公式によると、ツール検索が既定で有効で、セッション開始時に読み込まれるのはツール名とサーバーの指示だけです。そのため、サーバーを追加しても影響は小さいとされています。1サーバーあたりのツール数に固定の上限はなく、実際の限界はコンテキストの予算だと説明されています(Scale with MCP tool search)。

Q6. claude.aiで追加したサーバーが、Claude Codeに出てこないのはなぜですか。

公式によると、コネクタが取得されるのは、有効な認証方法がclaude.aiのサブスクリプションのログインのときだけです。ANTHROPIC_API_KEYなどが有効な場合は読み込まれません。/statusで認証方法を確認するよう案内されています(Use MCP servers from claude.ai)。

まとめ｜定義の洗い出しから始めて、止める・消す・絞るを記録に残す

MCPサーバーの見直しは、追加より地味な作業ですが、手順は決まっています。まずclaude mcp listとclaude mcp get、/mcpで現状を洗い出し、設定警告を確認します。次に、優先順位と照合の規則を踏まえて重複を整理します。そのうえで、止める・消す・認証を外すを使い分け、残すサーバーは提供元と権限の範囲を確かめます。

クローンしたリポジトリの.mcp.jsonは、起動方法によっては承認の確認が出ないことを前提に、disabledMcpjsonServersや--setting-sourcesで備えます。claude.aiのコネクタとプラグインのサーバーは、自分で追加した覚えがなくても読み込まれるため、棚卸しの対象に含めて確認します。判断は棚卸しシートに1行ずつ残すと、次回の見直しが短く済みます。

追加の手順に戻るときはMCPサーバーを追加する方法を、Claude Code全体の入口はClaude Codeの使い方を参照してください。