वेब UI, CLI या TUI से Model Context Protocol (MCP) सर्वरों का निरीक्षण, डिबग और दृश्य रूप से परीक्षण करें, जिसमें टूल/संसाधन अन्वेषण, अनुरोध लॉगिंग और OAuth समर्थन शामिल है।
Model Context Protocol (MCP) सर्वरों के निरीक्षण के लिए एक डेवलपर टूल। यह एक ही पैकेज, @modelcontextprotocol/inspector के रूप में आता है, जो सर्वर का निरीक्षण करने के तीन तरीके प्रदान करता है:
ये तीनों एक ही वैश्विक mcp-inspector बाइनरी के माध्यम से चलते हैं:
npx @modelcontextprotocol/inspector # web UI (default)
npx @modelcontextprotocol/inspector --cli # CLI
npx @modelcontextprotocol/inspector --tui # TUI
v1 से अपग्रेड कर रहे हैं? v1 → v2 माइग्रेशन गाइड पढ़ें — CLI फ़्लैग, नया
--configबनाम--catalogविभाजन, Node इंजन अपग्रेड, और अब क्या शामिल नहीं है।
रिपो रिपॉजिटरी स्थिति। यह इंस्पेक्टर की v2 लाइन है। सक्रिय विकास
v2/mainपर होता है (डेवलप ब्रांच — सभी v2 PR इसी को लक्षित करते हैं), जिसे माइलस्टोन रिलीज़ परmainमें मर्ज किया जाता है;mainडिफ़ॉल्ट ब्रांच है और नवीनतम रिलीज़ की गई v2 रखती है, जो npmlatestटैग पर प्रकाशित होती है। लीगेसी v1 लाइनv1/mainपर रहती है — केवल सुरक्षा फिक्स, सीधे उसी ब्रांच से npmv1-latestटैग पर प्रकाशित (npx @modelcontextprotocol/inspector@v1-latest)। ब्रांच/बोर्ड परंपराओं के लिएAGENTS.mdदेखें।
Node >=22.19.0 आवश्यक है।
npm install # at the repo root; postinstall cascades into every client
npm run build # web → cli → tui → launcher
दिन-प्रतिदिन वेब पुनरावृत्ति के लिए, Vite को सीधे चलाएँ — तेज़ HMR, कोई launcher बिल्ड आवश्यक नहीं:
cd clients/web && npm run dev
Launcher-संचालित स्क्रिप्ट निर्मित launcher चलाती हैं, इसलिए पहले बिल्ड करें:
npm run web # prod web launcher against clients/web/dist
npm run web:dev # web launcher in --dev mode (Vite)
v2 एक npm वर्कस्पेस नहीं है — clients/* के अंतर्गत प्रत्येक क्लाइंट अपना स्वयं का package.json और node_modules रखता है, और साझा कोड core/ में रहता है, जिसे @inspector/core बिल्ड-टाइम एलियास के माध्यम से उपभोग किया जाता है। core/ द्वारा आयात की जाने वाली प्रत्येक रनटाइम निर्भरता एक बार, रिपो-रूट package.json में घोषित की जाती है, और प्रत्येक क्लाइंट केवल वही घोषित करता है जो उस क्लाइंट को अकेले उपभोग करना होता है — उसका UI स्टैक, उसके बंडलर-इनलाइन पैकेज, उसके डेव टूलिंग — जो clients/cli और clients/launcher को अपनी कोई रनटाइम निर्भरता नहीं छोड़ता। निर्भरता जोड़ने का इसका क्या अर्थ है (रूट बनाम क्लाइंट, dependencies बनाम devDependencies, और बंडलर external सूचियाँ) local-dev स्किल में है।
inspector/
├── clients/
│ ├── web/ Web client (Vite + React + Mantine). src/ = browser app; server/ = Node backend
│ ├── cli/ CLI client (tsup bundle, @inspector/core alias)
│ ├── tui/ TUI client (Ink + React, tsup bundle)
│ └── launcher/ Shared launcher — provides the `mcp-inspector` bin, dispatches to web/cli/tui
├── core/ Shared code consumed via the `@inspector/core` alias (no package.json)
├── test-servers/ Composable MCP test servers + fixtures used by integration and smoke tests
├── scripts/ Root build/verify tooling (install cascade, smokes, the verify:* guards)
│ and repo automation run from CI (the dependency, Dependabot-alert and SDK sweeps)
├── docs/ Task-oriented guides — see below
├── specification/ Design/build specifications
├── .claude/skills/ Agent skills: the repo's procedures, invokable by name
├── AGENTS.md Contribution rules for agents AND humans
└── README.md You are here
| गाइड | कवरेज |
|---|---|
| आर्किटेक्चर | @inspector/core साझा पैकेज, और वेब क्लाइंट का "डंब कंपोनेंट्स" + Storybook दृष्टिकोण |
| परीक्षण और गुणवत्ता गेट | प्रत्येक validate / coverage / smoke / verify:* स्क्रिप्ट क्या कवर करती है, GitHub-CI-बनाम-लोकल-गेट विभाजन, और समर्थित ब्राउज़र |
| स्किल लेखन | ऐसी स्किल विवरण कैसे लिखें जो वास्तव में ट्रिगर हो, और eval केस जो इसे मापते हैं — काम करने वाले केस आकार, और ट्यूनिंग लूप |
| टेस्ट सर्वर | कंपोज़ेबल टेस्ट सर्वर और हर फीचर के लिए शोकेस कॉन्फ़िग — क्या चलाएँ, क्या क्लिक करें, और टूटे बिल्ड ने क्या किया |
| प्रकाशन | टारबॉल में क्या शिप होता है, पैकेजिंग इनवेरिएंट, और pack:verify |
| Docker | कंटेनर इमेज चलाना — पोर्ट, वॉल्यूम, और सीक्रेट कहाँ जाते हैं |
| v1 से v2 में माइग्रेट करना | CLI फ़्लैग मैपिंग, --config बनाम --catalog, Node इंजन अपग्रेड, env-var नाम बदलना |
| MCP सर्वर कॉन्फ़िगरेशन | इंस्पेक्टर किस सर्वर(सर्वरों) से जुड़ता है, और कॉन्फ़िग फ़ाइल प्रारूप |
| MCP ऐप की समीक्षा | स्वचालित ऐप-टूल समीक्षा के लिए CLI-फर्स्ट → वन-शॉट-वेब रेसिपी |
| MCP सर्वर का स्मोक-टेस्टिंग | शेल या CI जॉब के लिए कनेक्ट → लिस्ट → कॉल → एसर्ट वर्कफ़्लो: + , एग्ज़िट-कोड मैप, और OAuth को नॉन-इंटरैक्टिव रखना |
प्रत्येक क्लाइंट अपने स्वयं के फ़ोल्डर से स्व-सत्यापन करता है; रूट स्क्रिप्ट उन्हें श्रृंखलाबद्ध करती हैं। कोई समग्र रूट test स्क्रिप्ट नहीं है।
npm run validate # fast inner loop: format:check + lint + typecheck + build + unit tests
npm run coverage # the per-file ≥90% gate (lines/statements/functions/branches)
npm run local:gate # MANDATORY before pushing — a strict superset of GitHub CI
npm run local:gate नीचे दी गई हर जाँच को श्रृंखलाबद्ध करता है, साथ ही स्मोक और Storybook परीक्षणों को भी। परीक्षण और गुणवत्ता गेट स्टेज सूची का स्वामी है और बताता है कि प्रत्येक क्या कवर करता है और दो केवल-लोकल क्यों हैं; AGENTS.md में परीक्षण नियम स्वयं हैं।
AGENTS.md, CLAUDE.md, और स्किल्सAGENTS.md इस कोडबेस को बदलने का अनुबंध है, और यह मनुष्यों और AI एजेंटों दोनों पर समान रूप से लागू होता है। यह केवल एजेंट-विशिष्ट बॉयलरप्लेट नहीं है — इसमें प्रोजेक्ट के वास्तविक नियम हैं: संस्करण/लेबल परंपराएँ, TypeScript और Mantine/React मानक, परीक्षण और कवरेज आवश्यकताएँ, और अनिवार्य प्री-पुश गेट। बदलाव करने से पहले इसे पढ़ें, और जब आप संरचना, टूलिंग या नियम बदलते हैं तो इसे अद्यतित रखें।
रिपो की प्रक्रियाएँ — कमांड और लाइव ID वाली बहु-चरणीय रेसिपी — इसके बजाय .claude/skills/ में रहती हैं, प्रति प्रक्रिया एक निर्देशिका, ताकि वे केवल तभी लोड हों जब कार्य उन्हें माँगता है। वे सामान्य प्रतिबद्ध Markdown हैं: एक एजेंट जो स्किल्स को नहीं समझता वह उन्हें पढ़ सकता है, और AGENTS.md में मौजूद चीज़ों का एक सूचकांक होता है। Claude Code उपयोगकर्ता उन्हें नाम से आमंत्रित करते हैं (/release, /issue-triage, …)।
CLAUDE.md वह प्रवेश बिंदु है जिसे Claude Code स्वचालित रूप से लोड करता है; इसमें AGENTS.md शामिल है, इसलिए एजेंट और मनुष्य एक ही स्रोत से काम करते हैं। यदि आप एक अलग एजेंट का उपयोग करते हैं जो AGENTS.md पढ़ता है, तो आपको वही नियम मिलते हैं।
यहाँ उजागर करने योग्य एक प्रमुख नियम: सभी कार्य इश्यू-संचालित है। शुरू करने से पहले, v2 प्रोजेक्ट बोर्ड पर एक ट्रैकिंग इश्यू खोजें या बनाएँ; Closes #<issue> के साथ v2/main के विरुद्ध PR खोलें। बाहरी योगदान इश्यू के रूप में स्वीकार किए जाते हैं, पुल रिक्वेस्ट के रूप में नहीं — CONTRIBUTING.md देखें।
MIT।
--format jsonjq| Launcher और कॉन्फ़िग समेकन | launcher क्लाइंट को स्पॉन करने के बजाय इन-प्रोसेस क्यों चलाता है |