MCP Serverを自作したあと、最初に開きたくなるのがMCP Inspectorです。tools、resources、promptsをUIで見られ、stdioやHTTPの接続も切り替えられるので、AIコーディング環境へ入れる前の確認にはかなり便利です。
ただし、Inspectorで接続に成功したことは「そのServerを本番権限でAIエージェントへ渡してよい」という意味ではありません。2026年6月13日にMCP Inspector 0.22.0、MCP TypeScript SDK 1.29.0、公式README、MCP transport仕様、draft authorization仕様、security best practicesを確認した範囲では、最初に見るべき論点はServerの便利さではなく、Inspectorへ渡した権限の小ささです。
X/Twitter上ではCodex、Claude Code、MCP、外部コンテキスト、セッションをまたぐ記憶の話題が伸びやすく、MCP Serverを足したい需要は強く見えます。この記事ではその需要を入口にしつつ、技術的な判断は公式一次情報とローカル検証だけに寄せます。MCPの基本はMCPとは何か: Tools・Resources・Promptsと権限設計で扱っているので、ここではInspector検証時のproxy token、localhost binding、stdio、Streamable HTTP、secret、tool実行権限に絞ります。
3行まとめ
proxy tokenとlocalhost bindingを最初に確認します。
stdioとStreamable HTTPで見る権限境界を分けます。
read-only、dry-run、writeの順に段階を上げます。
Inspectorの価値は、接続できたことではなく、何を許可したかを説明できることにあります。
- MCP Inspectorは、自作Serverの接続確認だけでなく、AIコーディング環境へ渡す前の権限レビューに使うと価値が出ます。
- まず確認するのは、proxy token、localhost binding、
DANGEROUSLY_OMIT_AUTHを使っていないこと、HOST=0.0.0.0で不用意に外へ開いていないことです。 - stdioではcommand、env、cwdを検証用に落とし、Streamable HTTPではURL、Origin、Authorization、開発用tokenを本番から分けてからtoolを試します。
この記事でわかること
Client UIとProxyを権限境界として見ます。
command、arguments、cwd、env、secretを分けます。
URL、Authorization、Origin、開発用tokenを分けます。
検証結果と未確認項目を残します。
読後の目標は、Inspectorで何を見たかをレビュー可能な形にすることです。
- MCP InspectorのClient UIとProxyを、単なるローカル画面ではなく権限境界として見る理由
- proxy token、localhost binding、Origin validationを確認する順番
- stdio transportでcommand、arguments、cwd、env、secretを分ける具体的な見方
- Streamable HTTPでURL、Authorization、OAuth、開発用tokenを本番接続から切り離す考え方
- tools、resources、promptsをInspectorで見るときのread-only、dry-run、writeの段階分け
- MCP Inspector CLIをsmoke testに使うときの注意点
- AIコーディングエージェントへ接続する前に残す検証記録
前提知識
- 1Client
ブラウザでtools、resources、prompts、実行結果を確認します。
- 2Proxy
ブラウザUIとMCP Serverの間で接続を中継します。
- 3Server
stdioではprocess、HTTPではURLの先にある実装へ届きます。
- 4Logs
stdout、stderr、errorにsecretが混ざらないか確認します。
Inspectorは通信を眺めるだけでなく、実行権限や接続先を伴う開発者ツールです。
MCP Inspectorは、MCP Serverをテスト、デバッグするための公式開発者ツールです。公式READMEでは、ReactベースのMCP Inspector Clientと、Node.jsのMCP Proxyの2つで構成されると説明されています。Proxyは、ブラウザUIとMCP Serverをつなぐ橋渡しであり、stdio、SSE、streamable-httpの接続を扱えます。
ここで大事なのは、Proxyが「通信を眺めるだけの道具」ではないことです。stdio Serverを検証するとき、Inspectorは指定したcommandを起動し、そのprocessへJSON-RPCメッセージを送ります。HTTP Serverを検証するときは、指定したURLへ接続します。どちらの場合も、検証UIの裏側には実行権限、環境変数、接続先、token、ログが残ります。
TypeScriptでMCP Serverそのものを作る流れは、TypeScriptでMCPサーバーを作る: Tools・Resources・Promptsの最小構成に回します。GitHub read-onlyのような実装例は、TypeScriptでGitHub read-only MCPサーバーを作るを先に読むと、この記事のsecret分離やtool allowlistの話がつながりやすくなります。
結果: Inspector検証で合格にする条件
セキュリティ判断では単純な勝敗ではなく、各条件を説明できることを合格ラインにします。
MCP Inspectorでの最初の合格ラインは、「Serverに接続できた」ではなく、次の条件を説明できることです。
| 確認項目 | 合格にする状態 | 危ない状態 |
|---|---|---|
| Proxy認証 | 既定のrandom session tokenを使い、tokenを共有ログへ残さない | 面倒だから認証を無効化する |
| Binding | localhostで閉じる | 理由なくHOST=0.0.0.0で開く |
| stdio | 検証用command、検証用cwd、検証用envで起動する | 普段の開発shellと同じsecretを渡す |
| HTTP | 検証用URL、検証用Authorizationで接続する | production endpointに直接つなぐ |
| tool | metadata表示、read-only、dry-run、承認付きwriteの順に試す | 初回からwrite toolを実行する |
| ログ | tokenや顧客データが出ない形で保存する | 失敗時のresponse全文をそのまま共有する |
ローカルでは次の2つだけ確認しました。help全文は長いので本文には載せませんが、--config、--server、--cli、--transport、--server-urlを確認できました。
npm view @modelcontextprotocol/inspector version
npm view @modelcontextprotocol/sdk version
npx -y @modelcontextprotocol/inspector@0.22.0 --help確認時点の返り値は、@modelcontextprotocol/inspectorが0.22.0、@modelcontextprotocol/sdkが1.29.0でした。MCP周辺は更新が速いので、この記事の値は2026年6月13日の確認値として扱ってください。
MCP Inspectorは「接続できた」ではなく「何を許可したか」を見る道具
- 1Description
toolの説明が実際の副作用を伝えているか見ます。
- 2Input schema
repo、path、URL、ID、modeを狭める制約を見ます。
- 3Separation
read-onlyとwriteが同じtoolに混ざっていないか見ます。
- 4Error
token、request body、private URLがログへ出ないか見ます。
- 5Client
AI coding clientへ渡す前の承認条件を見ます。
UIにtoolが見えることと、そのtoolをAIへ渡してよいことは別です。
Inspectorを最初に開く目的は、Serverの機能を眺めることではありません。AIコーディング環境へ渡す前に、Serverがどんなcapabilityを公開し、どのtoolが副作用を持ち、どのtransportでどのsecretに届くのかを確認することです。
UIで見えるものと、実際に実行される権限は別物
InspectorのUIでtools一覧が見えても、そのtoolが安全とは限りません。名前がlist_issuesでも、内部で外部APIを広く読んでいるかもしれません。get_fileのようなread系toolでも、対象path、ref、repo、認証scopeが広ければ、社内情報を拾いすぎる可能性があります。
見る順番は次の通りです。
確認項目
- tool名とdescriptionが、実際の副作用を説明しているか
- input schemaに、対象repo、path、URL、ID、modeなどを狭める制約があるか
- read-onlyとwriteが同じtoolに混ざっていないか
- 失敗時にtoken、request body、社内path、private URLをログへ出さないか
- AIコーディングclient側で承認やallowlistを置ける粒度になっているか
MCP Serverを外部から選ぶ場合は、Server名だけで判断しない方がいいです。MCP Registryや既存Server選定の観点は、MCP Registryからサーバーを選ぶ前にでも整理しています。Inspectorは、その判断を自分の環境で再確認するための入口です。
需要シグナルは採用理由であって、仕様根拠ではない
CodexやClaude CodeでMCPを使いたい、外部コンテキストや永続メモリをつなぎたい、という話題は伸びやすいです。だからこそ、導入したくなる速度に対して、検証と権限レビューを先に置く必要があります。
根拠の置き方
この記事ではX上の投稿を仕様根拠には使いません。MCP Inspectorの挙動は公式READMEとDocs、transportやauthorizationの整理はMCP仕様、危険な権限設計の考え方はsecurity best practicesで確認します。市場の熱量と技術的な安全性は、別の証拠で判断します。
proxy tokenとlocalhost bindingは最初に確認する
通常の検証手順として扱いません。
固定tokenをチームチャットへ貼りません。
理由なくlocal processの入口を外へ開きません。
検証中のProxyは手元の境界で閉じます。
Proxy tokenとbindingは、Inspectorで最初に見る小さくて大事な境界です。
MCP InspectorのREADMEでは、Proxy Serverは既定で認証を要求し、起動時にrandom session tokenを生成すると説明されています。InspectorはそのtokenをURLへ埋めた状態でブラウザを開くことがあります。これは邪魔な追加手順ではなく、ブラウザUIからProxyへ到達できる人を絞る境界です。
DANGEROUSLY_OMIT_AUTHを便利設定として扱わない
Inspectorには認証を無効化するためのDANGEROUSLY_OMIT_AUTHがあります。名前の通り、通常の検証手順として使うものではありません。特に、MCP Serverがlocal processを起動する、filesystemを読む、社内APIやGitHubへつなぐ、databaseやticket systemへ届く場合、認証なしのProxyは検証用の穴になります。
避けたい組み合わせは、次の3つです。
避ける条件
| 設定 | なぜ避けるか |
|---|---|
DANGEROUSLY_OMIT_AUTH=true | Proxyへ届いたrequestを誰が出したか分けにくくなる |
| 固定tokenをチームチャットに貼る | tokenが検証期間を超えて残りやすい |
| 本番secretを渡した状態でInspectorを共有する | 検証UIの操作が本番権限の操作になる |
どうしても特殊な検証で認証を外す必要があるなら、使い捨てworkspace、使い捨てsecret、localhost限定、短時間起動、終了後のcredential失効までをセットにします。記事として推奨したいのは、認証を外すことではなく、なぜ外さないのかをチームで説明できる状態です。
HOST=0.0.0.0はlocal process executionの面を外に出す
READMEでは、InspectorのProxy ServerとClientは既定でlocalhostにbindするとされています。これは同じマシン上の開発用途としては自然です。一方、HOST=0.0.0.0で全interfaceにbindすると、ネットワーク上の別端末からも到達できる可能性が出ます。
ここで怖いのは、Web UIが見えることだけではありません。stdio Serverを検証している場合、Proxyはlocal commandを起動する側にいます。つまり、外へ開いたProxyは、設定次第でlocal process executionに近い能力を持つ面をネットワークへ見せます。
安全側の判断は単純です。
安全側の条件
- 個人検証ではlocalhostのまま使う
- チーム共有のために外へ開かない
- 共有が必要なら、Inspectorではなく検証ログ、CLI smoke結果、スクリーンショットではなく証跡テキストを共有する
- 外部接続の可否は、AIコーディングclientのnetwork allowlistやMCP server側の認可で別に管理する
CodexやAIコーディング環境でnetworkを広げる考え方は、Codexにインターネットアクセスを許可する前にのallowlist設計にも通じます。Inspectorのlocalhost bindingも、同じく「どこから届くか」を先に狭める話です。
Origin validationは「ローカルだから不要」ではない
READMEでは、DNS rebinding攻撃を防ぐためにOrigin headerを検証し、既定ではclient originだけを許可すると説明されています。追加のoriginはALLOWED_ORIGINSで設定できます。
許可するOriginの条件
これも、面倒なら広げるという扱いにはしません。開発用の別portからUIを触る必要がある場合だけ、許可するoriginを明示します。*のような広い指定を当然のように使うと、Proxy tokenやlocalhost bindingで作った境界を薄くしてしまいます。
stdio transportではcommand、env、cwdを検証用に落とす
stdioではServerのコードだけでなく、起動したprocessが持つ環境も検証対象です。
MCP transport仕様では、stdio transportはclientがMCP Serverをsubprocessとして起動し、stdin/stdoutでJSON-RPCメッセージをやり取りする形です。ServerはstdoutへMCP message以外を書いてはいけず、ログはstderrへ出すべき、とされています。
Inspectorからstdio Serverを起動するときも、この構造は変わりません。つまり、検証UIを開く前に見るべきものは、Serverのコードだけではなく、起動command、arguments、cwd、env、filesystem権限です。
npx @modelcontextprotocol/inspector node build/index.jsの前に見るもの
公式READMEでは、Server repositoryから次のように起動できる例が示されています。
実行前の確認項目
npx @modelcontextprotocol/inspector node build/index.js記事で勧めたいのは、このcommandをそのまま本番Serverへ向けることではありません。先に検証用configを作ります。
{
"mcpServers": {
"local-readonly-dev": {
"type": "stdio",
"command": "node",
"args": ["build/index.js"],
"env": {
"GITHUB_TOKEN": "ghp_dev_readonly_dummy",
"MCP_MODE": "readonly"
}
}
}
}実際にはtoken値をファイルへ直書きせず、ローカルの安全なsecret管理や環境変数から渡します。ここで伝えたいのは、Server名、mode、token scopeを検証用に分けることです。prodやadminに近い名前のenvをInspectorへ渡すなら、その時点で初回検証としては広すぎます。
cwdとfilesystemを狭くする
stdio Serverは、起動されたprocessのcwdやOS権限の影響を受けます。MCP Rootsやclient側のworkspace表示だけで安全になるわけではありません。Inspectorで起動するServerが、親workspace、home directory、SSH config、cloud credential、.env、生成済みlogsを読める状態なら、read toolでも情報を広く拾えます。
検証時は次のように分けます。
検証時の分離項目
| 項目 | 最初の設定 |
|---|---|
| cwd | 使い捨ての検証用repoまたはfixture directory |
| env | read-onlyの短命tokenだけ |
| filesystem | 対象fixture以外を読まなくても動く構成 |
| network | 必要なhostだけ許可 |
| logs | secretをmaskし、共有前に確認 |
MCP Serverがfilesystemや外部APIへ届く場合、Inspectorでの成功ログより、読めなかった範囲、渡さなかったsecret、止めたwrite toolを記録する方が大切です。
Streamable HTTP transportではURL、Origin、Authorizationを分けて見る
stdioとHTTPではcredentialの持ち方が違うため、同じ安全確認としてまとめません。
current transport仕様では、標準transportとしてstdioとStreamable HTTPが説明されています。Inspector側は設定でstdio、sse、streamable-httpを扱えますが、HTTP Serverを検証するときはstdioと違う面を見ます。
stdioではlocal processの起動条件が中心でした。Streamable HTTPでは、接続先URL、Authorization header、OAuthやtokenのscope、Origin、CORS、network boundaryが中心になります。
HTTP-based transportでは認可仕様の前提が変わる
MCP draft authorization仕様では、authorizationはMCP実装にとってoptionalであり、HTTP-based transportを使う実装は仕様に従うべき、とされています。一方、stdio transportではこのauthorization仕様に従うのではなく、環境からcredentialを取得する方針が示されています。
つまり、stdioとHTTPでは「どこでcredentialを持つか」が違います。
transportごとの確認項目
| transport | credentialの見方 | 最初に確認するもの |
|---|---|---|
| stdio | process envやlocal credential | command、cwd、env、filesystem |
| Streamable HTTP | requestのAuthorizationやOAuth | URL、token scope、Origin、server側認可 |
HTTP ServerをInspectorで見るときは、http://localhost:3000/mcpなのか、社内dev環境なのか、本番URLなのかを最初に固定します。本番URLへ直接つないで、UIでtoolを試すのは避けます。検証用URL、検証用tenant、検証用tokenを作り、write toolはdry-runまたは承認付きの状態で見ます。
URLとAuthorizationを同じメモに貼らない
Inspectorの設定やURL query parameterには、transportやserverUrlを入れられます。ここで注意したいのは、接続先URLとtokenを同じメモ、同じチャット、同じissueに貼らないことです。
共有すべきなのは、次のような情報です。
共有してよい情報
transport: streamable-http
serverUrl: https://mcp-dev.internal.invalid/mcp
auth: dev-only token, read-only scope, expires 2026-06-14
tested tools: tools/list, resources/list, readonly-search
not tested: create-ticket, update-issue, deploytokenそのものは共有しません。ログへ出た場合は失効します。Inspectorでの検証結果は、成功したtoolだけでなく、未実行のwrite tool、失敗した認可、意図的に渡さなかったscopeまで残すと、AIコーディングclientへ渡す前のレビューがしやすくなります。
tool実行権限はread-only、dry-run、writeの順で段階的に試す
- Metadata
tools/list、resources/list、prompts/listだけを見ます。
- Read-only
検証用データに対して読むだけのtoolを実行します。
- Dry-run
write系toolを実際には書き込まないmodeで試します。
- Approved write
人間承認付きで検証環境にだけ書き込みます。
- Production
本番writeは本番client側の承認フローで扱います。
便利なUIであっても、初回からwrite toolを押す手順にはしません。
Inspectorでtools一覧が出たら、すぐに全部実行したくなります。ここで順番を決めておかないと、便利なUIがそのまま危険な手動実行画面になります。
tool説明文とinput schemaだけで安全性を判断しない
toolのdescriptionは、AIエージェントがtoolを選ぶための重要な情報です。しかし、descriptionだけで安全性は決まりません。Inspectorで見るべきなのは、description、input schema、実行結果、失敗時のerror、ログ、外部サービス側の副作用です。
最初のラダーはこれで十分です。
評価基準
- metadataだけを見る:
tools/list、resources/list、prompts/list - read-only toolを検証用データで実行する
- dry-run付きwrite toolを、実際には書き込まないmodeで実行する
- 人間承認付きwriteを検証環境で実行する
- 本番writeはInspectorではなく、本番client側の承認フローで扱う
GitHub、Slack、Linear、Jira、Notion、DB、クラウドCLIのように外部状態へ影響するtoolは、Inspectorで直接本番操作をしない設計にします。Inspectorは危険なtoolを発見する場であって、本番writeの操作卓ではありません。
isErrorや失敗responseもレビュー対象にする
成功結果だけを見ると、Serverの危ない挙動を見落とします。失敗時にresponse本文をそのまま返すServerは、API errorにtoken、private URL、request body、顧客IDを混ぜてしまうことがあります。
Inspectorであえて確認したい失敗条件は、次の通りです。
失敗時の確認項目
- tokenがないとき、どのerrorを返すか
- 権限が足りないとき、scopeや内部URLを出しすぎないか
- 存在しないresourceを指定したとき、pathやSQL、stack traceを出さないか
- write toolをread-only modeで呼んだとき、確実に拒否するか
- retry時に同じ副作用を二重実行しないか
AIエージェントに渡す前に、成功時の便利さより、失敗時に漏れないこと、止まること、再実行しても壊れないことを確認します。
MCP Inspector CLIは再現性確認に使い、長期運用の代替にしない
- 1UI確認
tools、resources、prompts、errorの見え方を確認します。
- 2CLI smoke test
同じServerへ同じ条件で短い確認を実行します。
- 3Record
passだけでなくblockedにしたtoolも残します。
- 4Client operation
長期運用はclient側の承認、ログ、監査で守ります。
CLIかUIかではなく、どのconfig、secret、toolを実行したかが安全性を決めます。
MCP InspectorにはCLI modeがあります。公式READMEでは、--cliを使ってtools、resources、promptsを操作でき、--method tools/listや--method tools/callの例が示されています。UIで一度見た確認を、CI前のsmoke testやローカル再現手順に落とすには便利です。
npx @modelcontextprotocol/inspector --cli --config mcp.dev.json --server local-readonly-dev --method tools/listただし、CLIだから安全というわけではありません。CLIも同じServerへ接続し、同じtoolを実行します。安全性は、UIかCLIかではなく、どのconfig、どのtransport、どのsecret、どのtoolを実行したかで決まります。
CLI smoke testで残すもの
チームで扱うなら、最低限この程度は記録します。
記録する項目
date: 2026-06-13
inspector: @modelcontextprotocol/inspector 0.22.0
server: local-readonly-dev
transport: stdio
command: node build/index.js
env: dev readonly token, no production secret
methods:
- tools/list: pass
- resources/list: pass
- readonly-search: pass
blocked:
- create-issue
- update-ticket
- deployここで重要なのは、passした項目だけでなく、blockedにしたtoolを残すことです。AIコーディングclientへ渡すとき、人間のreviewerが「何を確認したか」だけでなく「何を確認していないか」を見られるようになります。
長期運用はInspectorではなくclient側の承認とログで守る
Inspectorは開発者ツールです。チームの通常運用で、毎回Inspectorを開いて手動承認する設計にはしません。通常運用では、AIコーディングclient側のapproval、sandbox、MCP server allowlist、API側のscope、監査ログ、CIのdry-runを組み合わせます。
Inspectorは導入前レビュー、Server更新時の差分確認、incident後の再現確認に使います。日常運用の境界は、InspectorのUIではなく、本番clientとServer側に置きます。
失敗点: 起動できたのに危ない状態
Inspector検証では、失敗で止まることより、広い権限で成功してしまうことに注意します。
Inspector検証で起きやすい失敗は、エラーで止まることより、うまく動いてしまうことです。接続できた、tool一覧が出た、read toolが動いた、write toolも通った。そこで満足すると、どの権限で通ったのかを見落とします。
よくある危ないパターン
戻し方の基準
| パターン | 何が危ないか | 戻し方 |
|---|---|---|
| 個人の本番PATをenvに入れる | Inspectorのmanual testが本番API権限になる | 検証用tokenを作り直し、既存tokenを失効 |
HOST=0.0.0.0で共有する | local process実行面がネットワークへ出る | localhostに戻し、ログだけ共有 |
DANGEROUSLY_OMIT_AUTHを常用する | Proxy tokenの境界が消える | 既定認証に戻す |
| write toolを初回から実行する | 副作用と承認の確認前に外部状態が変わる | dry-run modeを作る |
| error全文を貼る | token、URL、内部pathが混ざる | maskしてから共有 |
失敗ログを残すなら、raw responseをそのまま貼るのではなく、status、method、tool名、入力の種類、mask済みerror、対応結果に分けます。秘密情報を含む可能性があるログは、記事、issue、チャットへ貼らないでください。
導入しない方がよいケース
次の条件に当てはまるServerは、少なくともAIコーディング環境へすぐ接続しない方がいいです。
導入を止める条件
- tool名とdescriptionから副作用が読めない
- read-onlyとwriteが同じtoolに混ざっている
- 本番secretがないと起動できない
- 失敗時にstack traceや内部URLを返す
- HTTP Serverの認可がなく、network境界だけに依存している
- stdio Serverが起動時に不要な外部通信やfile scanを行う
- Inspector用configと本番client用configを分けられない
この段階で止めるのは、後ろ向きな判断ではありません。MCP ServerはAIエージェントが自律的に選び得るtool面です。人間がUIで一回成功しただけでは、エージェント運用時の安全性は確認できません。
実務で使うなら、AI client接続前のチェックリストを残す
チェックリストは安心の演出ではなく、未確認項目を見えるようにするために残します。
最後に、Inspector検証からAIコーディング環境へ移る前のチェックリストを残します。
接続前の確認項目
| 項目 | 確認 |
|---|---|
| Inspector version | @modelcontextprotocol/inspectorの確認日とversionを書いた |
| Server version | commit、package version、build commandを書いた |
| transport | stdioかStreamable HTTPかを分けた |
| proxy token | tokenを共有せず、認証を無効化していない |
| binding | localhostで閉じ、外部公開していない |
| secret | 検証用tokenだけを使い、本番secretを渡していない |
| tools | read-only、dry-run、writeを分けた |
| resources | 読める範囲をfixtureや検証データに限定した |
| prompts | promptに秘密情報や危険な承認省略がない |
| logs | error、stdout、stderrにsecretが出ない |
| AI client | approval、sandbox、allowlist、human reviewを別途設定した |
| rollback | token失効、config削除、Server停止の手順がある |
個人検証では、この表を短く埋めるだけでも十分です。チーム導入では、owner、対象repo、接続先、許可tool、禁止tool、更新時の再検証担当まで残します。MCP Server Starter Kitのようなテンプレートを使う場合も、テンプレート自体より、このチェックリストを埋められるかを採用条件にしてください。
セキュリティ・コスト注意
本番secretをInspectorへ渡しません。
write toolはdry-runと人間承認を持たせます。
AuthorizationとOriginを確認します。
cwd、env、filesystem、networkを検証用に落とします。
API、CI、model token、DB queryの再実行回数を決めます。
コストや事故は、Inspectorで押したtoolの裏側にある外部サービスから生まれます。
MCP Inspector自体の利用料金より、実際にコストやリスクを作るのは接続先です。GitHub API、社内検索、RAG、DB、チケット更新、クラウド操作、CI再実行、モデルAPI呼び出しなど、toolの裏側で動くものを見ます。
セキュリティ面では、次の原則を外さないでください。
セキュリティ原則
- 本番secretをInspectorへ渡さない
- read-onlyから始める
- write toolはdry-runと人間承認を持つ
- HTTP ServerはAuthorizationとOriginを確認する
- stdio Serverはcwd、env、filesystem、networkを検証用に落とす
- Inspectorの成功結果だけで本番clientへ接続しない
コストの見方
コスト面では、toolの再実行に注意します。Inspectorで何度もtoolを押すと、外部API rate limit、課金API、CI時間、モデルtoken、DB queryが積み上がることがあります。検証用tenantやfixtureを使い、実行回数と上限を決めてから試します。
MCP仕様やAIコーディング環境の更新差分を追いたい場合は、AI Dev Lab Japanのニュースレターで、実務導入に影響がある変更を拾えるようにしています。チームでMCP権限レビューやInspector検証手順を整えたい場合は、お問い合わせから相談できます。
FAQ
InspectorだけでServer全体の安全性は確認しきれません。
単純な優劣ではなく、見る境界が違います。
通常の検証手順としては使いません。
smoke testには便利ですが、長期運用の承認フローではありません。
迷ったら、どのsecretで、どのtoolを、どの範囲へ実行するのかに戻ります。
MCP Inspectorを使えばServerの安全性は確認できますか？
確認できるのは一部です。Inspectorはtools、resources、prompts、transport、実行結果、errorを観察するのに便利ですが、Serverの供給元、依存パッケージ、認証設計、外部API scope、運用時の承認、監査ログまでは別に確認します。
stdioとStreamable HTTPはどちらが安全ですか？
単純な優劣では決まりません。stdioはlocal process、cwd、env、filesystemの影響を強く受けます。Streamable HTTPはURL、Authorization、Origin、OAuth、network境界の影響を受けます。どちらも、検証用secret、read-only、dry-run、承認付きwriteの段階分けが必要です。
DANGEROUSLY_OMIT_AUTHはローカルなら使ってもよいですか？
通常の検証手順としては使わない方がよいです。名前の通り危険側の設定です。使うとしても、使い捨てworkspace、短命token、localhost限定、短時間起動、終了後のcredential失効まで含めた例外対応にします。
Inspector CLIをCIに入れてもよいですか？
read-onlyのsmoke testなら検討できます。ただし、本番secretを渡さず、実行するmethodとtoolを限定し、出力ログをmaskし、write toolはdry-runにしてください。CLIはUIより安全な仕組みではなく、再現性を上げるための入口です。
AIコーディングclientへ接続するタイミングはいつですか？
Inspectorでmetadata、read-only、dry-run、失敗時error、ログ、secret分離を確認し、client側のapproval、sandbox、allowlist、人間レビューを設定してからです。Inspectorで接続できた直後に本番clientへ入れるのは早すぎます。
次に読むなら
参照した主な情報源
- MCP Inspector Docs: https://modelcontextprotocol.io/docs/tools/inspector
- MCP Inspector GitHub repository: https://github.com/modelcontextprotocol/inspector
- MCP Inspector Releases: https://github.com/modelcontextprotocol/inspector/releases
- MCP Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
- MCP draft Authorization specification: https://modelcontextprotocol.io/specification/draft/basic/authorization
- MCP Transports specification 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
更新履歴
- 2026-06-13
MCP Inspector 0.22.0とMCP TypeScript SDK 1.29.0を確認しました。
- 仕様
MCP transports仕様、draft authorization仕様、security best practicesを確認しました。
- CLI
npxでInspector helpを確認し、config、server、cli、transport、server-urlを見ました。
MCPまわりは更新が早いため、確認日とversionを一緒に扱います。
- 2026-06-13: MCP Inspector 0.22.0、MCP TypeScript SDK 1.29.0、公式Docs、GitHub README、release、MCP transports仕様、draft authorization仕様、security best practicesを確認。
npx -y @modelcontextprotocol/inspector@0.22.0 --helpで--config、--server、--cli、--transport、--server-urlを確認しました。