mcpsnoop

MCP के लिए Wireshark। एक पारदर्शी प्रॉक्सी जो आपके AI क्लाइंट और आपके MCP सर्वर के बीच हर वास्तविक टूल कॉल को आपके टर्मिनल में लाइव दिखाता है।

mcpsnoop demo

समस्या

आधिकारिक MCP Inspector अपने स्वयं के क्लाइंट के रूप में कनेक्ट होता है, इसलिए यह कभी नहीं देखता कि आपका क्लाइंट (Cursor, Claude Code, Codex) वास्तव में आपके सर्वर को क्या भेजता है। और जो भी अनुरोध आने का इंतज़ार करता है, वह उस कॉल को नहीं दिखा सकता जो मॉडल ने कभी नहीं की, या गलत तर्कों के साथ की। जब कोई टूल चुपचाप कॉल नहीं होता, क्षमताएँ मेल नहीं खातीं, या कोई कॉल बस अटक जाती है, तो आप लॉग खंगालने और अनुमान लगाने में फँसे रह जाते हैं।

अपने सर्वर कमांड को इसके साथ लपेटें और हर JSON-RPC फ्रेम को लाइव देखें, जब आपका वास्तविक क्लाइंट और सर्वर बात करते हैं।

`redact-key`, `redact-value`, और `redact-path` को अपनी-अपनी पंक्तियों में दोहराएँ ताकि इनमें से प्रत्येक को एक से अधिक बार जोड़ा जा सके। ये सभी कुंजियाँ हैं जिन्हें यह समर्थन करता है। फ़ाइल केवल वर्तमान कार्यशील निर्देशिका में देखी जाती है, मूल निर्देशिकाओं में नहीं। स्पष्ट कमांड-लाइन फ़्लैग कॉन्फ़िग फ़ाइल के मानों को ओवरराइड करते हैं। ## Commands | Command | What it does | |---|---| | `mcpsnoop -- <server>` | wrap a stdio server as a transparent shim | | `mcpsnoop` | open the live TUI | | `mcpsnoop http --target <url>` | proxy a streamable-HTTP server | | `mcpsnoop export` | render a session to json, html, text, har, or otlp | | `mcpsnoop check` | fail CI on errors, invalid frames, warnings, routing mismatches, hung calls, late results, or a latency budget | | `mcpsnoop baseline` | inspect, accept, or reset trusted tool definitions | | `mcpsnoop diff` | compare tools and calls across two captured sessions | | `mcpsnoop open` | open a saved session in the TUI | | `mcpsnoop inventory` | list every server that has run through mcpsnoop on this machine | | `mcpsnoop stats` | fold every stored capture into one row per server and tool | | `mcpsnoop prune` | delete saved session logs older than a cutoff | | `mcpsnoop wrap <server>` | route one of Claude Desktop's servers through mcpsnoop | | `mcpsnoop unwrap <server>` | put that server's entry back the way it was | | `mcpsnoop remote <user@host>` | print the SSH tunnel command | | `mcpsnoop demo` | play a scripted session | पूरी सूची के लिए `mcpsnoop help` चलाएँ, या किसी एक के फ़्लैग के लिए `mcpsnoop help <command>` चलाएँ। ## How it compares | | MCP Inspector | mcpsnoop | |---|:---:|:---:| | Sees your real client and server traffic | no | yes | | Flags hung calls and stream errors | no | yes | | Flags stray output that corrupts the stream | no | yes | | Flags malformed JSON-RPC frames | no | yes | | Detects tool definition drift after approval | no | yes | | Interactive terminal UI | no | yes | | Zero-config, no flags or ordering | no | yes | | Capability inspector | partial | yes | | Replay a captured call | no | yes, over stdio and over HTTP | | Session export (json / html / text / otlp) | no | yes | | Single binary, no runtime deps | no | yes | ## Install ### npm कोई Go टूलचेन आवश्यक नहीं है। अधिकांश MCP सर्वर Node या Python में लिखे गए हैं, इसलिए यह सबसे छोटा रास्ता है।```bash npx mcpsnoop -- node build/index.js

`--older-than` आवश्यक है (कोई डिफ़ॉल्ट नहीं है जो कुछ भी हटा दे) और `30d` जैसी दिनों की गिनती या `72h` जैसी Go अवधि स्वीकार करता है। टूल बेसलाइन को अकेला छोड़ दिया जाता है, क्योंकि बेसलाइन सत्र के बजाय सर्वर लेबल द्वारा कुंजीबद्ध होती है। क्योंकि यह वास्तविक पाइप में बैठता है, Inspector की तरह किनारे पर नहीं, यह ठीक वही देखता है जो आपका वास्तविक क्लाइंट और सर्वर एक-दूसरे से कहते हैं, चाहे सर्वर किसी भी भाषा में लिखा गया हो। ## कीबाइंडिंग | Key | Action | | Key | Action | |---|---|---|---|---| | `enter` | निरीक्षण / अंदर जाएँ | | `/` | फ़िल्टर | | `esc` | वापस | | `:` | कमांड | | `j` / `k` | हिलाएँ | | `r` / `R` | रीप्ले / संपादित करें और रीप्ले | | `g` / `G` | ऊपर / नीचे | | `c` | क्षमताएँ | | `ctrl-f` / `ctrl-b` | पेज | | `s` | टूल सारांश | | `p` | रोकें | | `y` | कॉपी | | `shift`+`<key>` | कॉलम द्वारा क्रमबद्ध करें | | `e` | निर्यात | | `ctrl-d` | सत्र हटाएँ | | `f` | अनुसरण करें | | `?` | सहायता | | | | पूरी सूची के लिए ऐप में `?` दबाएँ। ## स्ट्रीम को फ़िल्टर करना किसी सत्र में `/` दबाएँ और स्पेस-पृथक टोकन को मिलाएँ, ANDed। सादा पाठ विधि, टूल, id और पेलोड से मेल खाता है। | Token | Filters by | Example | |---|---|---| | `tool:` | टूल नाम | `tool:search` | | `method:` | JSON-RPC विधि | `method:tools/call` | | `id:` | अनुरोध id, और उसे जारी रखने वाला कोई भी रीट्राय | `id:7` | | `task:` | कार्य id | `task:01J...` | | `dir:` | दिशा (`c2s`, `s2c`) | `dir:s2c` | | `kind:` | फ़्रेम प्रकार (`req`, `resp`, `notify`, `stderr`, `invalid`) | `kind:invalid` | | `status:` | कॉल परिणाम (`ok`, `error`, `cancel`, `late`, `cancelled`, `pending`, `bad`, `warn`, `mismatch`, या `401` जैसा HTTP स्टेटस) | `status:error` | विशिष्ट पाने के लिए टोकन स्टैक करें।```text tool:search status:pending # in-flight calls to one search tool status:cancel # calls the client gave up on (status:cancelled is a cancelled task) status:late # results that arrived after the cancellation method:tools/call status:error # tool calls that failed dir:s2c kind:req # server-initiated requests (servers before 2026-07-28)

| प्रारूप | आपको क्या मिलता है | |---|---| | `json` | सहसंबद्ध कॉल, प्रति-टूल गणना और p50/p95/p99 विलंबता, सबसे धीमी कॉल, क्षमताएं, और कच्चे फ्रेम | | `html` | एक स्व-निहित ब्राउज़र फ़ाइल जिसमें खोज और संक्षिप्त करने योग्य JSON होता है | | `text` | एक सुंदर सादा-पाठ डंप | | `har` | प्रति सहसंबद्ध कॉल एक प्रविष्टि, ब्राउज़र डेवटूल्स और HAR पढ़ने वाली किसी भी अन्य चीज़ में खोलने योग्य | | `otlp` | OTLP JSON जिसमें प्रति सहसंबद्ध कॉल एक स्पैन होता है, W3C ट्रेस संदर्भ के साथ जो कॉलर ट्रेस को जोड़ता है जहां यह मौजूद है, और अन्यथा प्रति सत्र एक ट्रेस | MCP HTTP नहीं है, इसलिए HAR प्रविष्टि का URL, स्थिति कोड, और समय प्रत्येक कॉल का एक जानबूझकर मानचित्रण है, न कि वायर ट्रांसक्रिप्ट। OTLP के लिए, एक अनुरोध का `_meta.traceparent` उस कॉल के ट्रेस और पैरेंट स्पैन आईडी प्रदान करता है, और `_meta.tracestate` स्पैन पर साथ चलता है। जब traceparent अनुपस्थित या अमान्य होता है, mcpsnoop सत्र-व्युत्पन्न ट्रेस रखता है और कोई स्थिति नहीं ले जाता। mcpsnoop अवलोकन करता है, भाग नहीं लेता, इसलिए यह अपनी कोई विक्रेता प्रविष्टि नहीं जोड़ता और कॉलर की स्थिति को अपरिवर्तित पास करता है।```bash mcpsnoop export -T html -o out.html # an HTML file to open in a browser mcpsnoop export -T text server.py-48213-7f3a1c9e2b04 # a specific session, as text mcpsnoop export -T json | jq # the newest session, piped to jq mcpsnoop export -T har -o session.har # a HAR file to open in browser devtools mcpsnoop export -T otlp -o trace.json # import into an OTLP-compatible tracing backend

ये फ़्लैग निर्यात की गई फ़ाइल या इन-मेमोरी TUI दृश्य को फिर से लिखते हैं, कभी भी स्रोत JSONL को नहीं। `export` उस आउटपुट को अस्वीकार करता है जो अपने इनपुट के समान फ़ाइल का नाम देता है, और एक अस्थायी फ़ाइल के माध्यम से लिखता है जिसे बाद में स्थान पर नाम बदल दिया जाता है, इसलिए एक रन जो विफल हो जाता है वह पिछली फ़ाइल को अक्षुण्ण छोड़ देता है। किसी टूल का `inputSchema` और `outputSchema`, जैसा कि `tools/list` परिणाम में विज्ञापित किया गया है, `--redact-key` और `--redact-secrets` द्वारा अछूता छोड़ दिया जाता है, तीन कारणों से। - स्कीमा के अंदर एक नाम एक मान के बजाय एक प्रकार की घोषणा है। - नाम स्वयं किसी भी तरह लॉग में रहता है। - `token` नामक प्रॉपर्टी के अंतर्गत सबस्कीमा को साफ़ करने से टूल की अपनी जाँचें भी साथ चली जाएँगी। छूट केवल उसी स्थिति पर लागू होती है, इसलिए एक तर्क जो संयोगवश `inputSchema` कहलाता है, किसी भी अन्य की तरह साफ़ किया जाता है, और यह `default`, `const`, `examples` और `enum` पर रुक जाता है, जिनमें संरचना के बजाय डेटा होता है। उपयोग करें `--redact-path` किसी स्कीमा के अंदर की चीज़ का नाम देने के लिए, या `--redact-value`, जो टेक्स्ट से मेल खाता है चाहे वह कहीं भी हो, सिवाय उन दो कीवर्ड्स के जिन्हें mcpsnoop पार्स करता है, `type` और `x-mcp-header`। प्रत्येक फ़्लैग जिस तक पहुँचता है वह भिन्न होता है, इसलिए अनुमान लगाने के बजाय परिणाम जाँचें। सभी चार JSON-RPC पेलोड को साफ़ करते हैं, और `--redact-key`, `--redact-path` और `--redact-secrets` केवल उन्हीं तक पहुँचते हैं। केवल `--redact-value` stderr, अन्य गैर-JSON टेक्स्ट, और स्ट्रिंग के अंदर के हिस्से को भी साफ़ करता है। एक `Mcp-Param-*` हेडर को उस बॉडी मान के साथ साफ़ किया जाता है जिसे वह प्रतिबिंबित करता है। अन्य एनवलप मेटाडेटा, सर्वर लेबल, `Mcp-Name`, `Mcp-Method` और HTTP स्थिति, को वैसे ही छोड़ दिया जाता है जैसे कैप्चर किया गया था। रिडक्शन सर्वोत्तम प्रयास है, इसलिए एक अलग आउटपुट पथ का उपयोग करें और साझा करने से पहले परिणाम पढ़ें। ### पूर्ण किए गए कॉल्स को OTLP कलेक्टर पर स्ट्रीम करें प्रॉक्सी चलते समय स्पैन भेजें, इसे OTLP/HTTP JSON ट्रेस एंडपॉइंट पर इंगित करके। कलेक्टर प्रमाणीकरण या टेनेंट के लिए `--otlp-header` दोहराएँ हेडर।```bash mcpsnoop \ --otlp-endpoint http://localhost:4318/v1/traces \ --otlp-header "Authorization=Bearer $OTLP_TOKEN" \ -- node build/index.js mcpsnoop http \ --target http://localhost:3000/mcp \ --otlp-endpoint http://localhost:4318/v1/traces

रिपोर्ट उन टूल्स को दिखाती है जो जोड़े या हटाए गए, विवरण और `inputSchema` परिवर्तन, मेल खाते टूल कॉल जिनकी स्थिति बदली, और उल्लेखनीय अवधि में बदलाव। कॉल टूल नाम और तर्कों द्वारा मिलाए जाते हैं, इसलिए पुनः क्रमबद्ध कॉल फिर भी सही ढंग से तुलना करते हैं। डिफ़ॉल्ट रूप से, अवधि परिवर्तन कम से कम 100 ms और 2x से भिन्न होने चाहिए। उन सीमाओं को समायोजित करने के लिए `--duration-threshold` और `--duration-ratio` का उपयोग करें। रीग्रेशन पर CI को गेट करने के लिए `--exit-code` पास करें। यह गैर-शून्य निकास तब करता है जब बाद का सत्र: - कोई टूल हटाता है - किसी टूल का विवरण, शीर्षक, इनपुट स्कीमा, आउटपुट स्कीमा या एनोटेशन बदलता है - ऐसा कॉल होता है जिसकी स्थिति खराब हो गई - धीमा हो जाता है आइकन परिवर्तन ऐसा नहीं करता, क्योंकि यह बदलता है कि टूल कैसा दिखता है बिना यह बदले कि वह क्या करता है। सुधार, जिसका अर्थ है जोड़े गए टूल, ठीक किए गए कॉल और गति वृद्धि, फिर भी शून्य निकास करते हैं। ## CI में सत्रों की जाँच करना किसी रिकॉर्ड किए गए एजेंट रन को त्रुटियों, स्ट्रीम भ्रष्टाचार, प्रोटोकॉल चेतावनियों, रूटिंग-हेडर बेमेल, उन कॉलों पर गेट करें जिन्हें कभी प्रतिक्रिया नहीं मिली, छोड़े गए फ्रेम जो कैप्चर को अधूरा छोड़ देते हैं, टूल-परिभाषा विचलन, या पुराने प्रोटोकॉल सुविधाओं के उपयोग पर।```bash mcpsnoop check [--format text|junit|sarif] [--fail-on error,invalid,warn,mismatch,pending,late-result,drift,deprecated,incomplete,schema] [session-id|log.jsonl|-]

सिग्नल

विफल होता है

error

एक कॉल जिसका उत्तर JSON-RPC त्रुटि के साथ दिया गया, isError चिह्नित परिणाम, या कोई कार्य जो विफलता में समाप्त हुआ

invalid

प्रोटोकॉल चैनल पर एक फ्रेम जो मान्य JSON-RPC नहीं है, आमतौर पर सर्वर stdout पर लॉगिंग कर रहा हो

warn

एक फ्रेम जो MCP या JSON-RPC विनिर्देश द्वारा निर्धारित अपेक्षा को तोड़ता है

mismatch

एक रूटिंग हेडर जो बॉडी से असहमत है, बैच पर सवार है, या जहाँ संशोधन इसे आवश्यक बनाता है वहाँ अनुपस्थित है

pending

एक अनुरोध जो कैप्चर समाप्त होने पर भी खुला था, इसलिए कॉलर को प्रतीक्षा में छोड़ दिया गया

late-result

एक प्रतिक्रिया जो उसके अनुरोध को रद्द करने के बाद पहुँची

drift

बेसलाइन स्वीकृत होने के बाद विज्ञापित टूल परिभाषा बदलना

deprecated

एक सुविधा जिसे विनिर्देश ने अप्रचलित घोषित किया है

incomplete

ऊपर की ओर छोड़े गए फ्रेम, जो हर अन्य गणना को कुल के बजाय न्यूनतम सीमा बनाते हैं

schema

एक विज्ञापित स्कीमा जो ऐसे निर्माण या बोली का उपयोग करती है जो क्लाइंट्स के बीच खराब यात्रा करती है

एक रिलीज़ पिन करें, जो भी आप चाहें। सबसे नया [रिलीज़ पेज](https://github.com/kerlenton/mcpsnoop/releases) पर है। जानबूझकर कोई फ्लोटिंग `v1` नहीं है। पिन की गई रिलीज़ वही बाइनरी है जिसे एक्शन इंस्टॉल करता है, इसलिए दोनों कभी असहमत नहीं हो सकते और पुराना होने के लिए कोई डिफ़ॉल्ट वर्ज़न नहीं है। | इनपुट | | |---|---| | `session` | जाँचने के लिए `.jsonl` कैप्चर, रिपॉज़िटरी रूट के सापेक्ष। आवश्यक | | `fail-on` | `--fail-on` के रूप में, डिफ़ॉल्ट रूप से वही जो CLI डिफ़ॉल्ट करता है | | `args` | कोई अन्य `check` फ़्लैग, कमांड लाइन की तरह उद्धृत। `--format` अस्वीकार कर दिया जाता है, क्योंकि एक्शन रिपोर्ट पढ़ता है | | `upload-sarif` | रिपोर्ट को कोड स्कैनिंग पर भेजें। `true` | | `category` | कोड स्कैनिंग नेमस्पेस। `mcpsnoop`. मैट्रिक्स के प्रत्येक चरण के लिए इसे बदलें, अन्यथा चरण एक-दूसरे को अधिलेखित कर देते हैं | | `fail-on-findings` | किसी फाइंडिंग पर जॉब को विफल करें। `true`. अलर्ट दर्ज करने के लिए `false` सेट करें और कोड स्कैनिंग के आवश्यक चेक को निर्णय लेने दें | | `version` | कौन सा mcpsnoop इंस्टॉल करना है। डिफ़ॉल्ट रूप से वह रिलीज़ जिसे आपने पिन किया है | | `install` | `false` जब mcpsnoop पहले से ही PATH पर है, जो उस प्लेटफ़ॉर्म पर रास्ता है जिसके लिए कोई रिलीज़ नहीं बनाई गई है | आउटपुट `outcome`, `sarif` और `exit-code` हैं। `outcome` `passed`, `findings`, या `error` है, और तीसरे को अलग से संभालना उचित है। इसका मतलब है कि कुछ भी जाँचा नहीं गया, जो कुछ न मिलने के समान नहीं है। **एक रन जो जाँच नहीं कर सका, वह जॉब को विफल कर देता है चाहे `fail-on-findings` कुछ भी कहे**, क्योंकि एक पाइपलाइन जो कुछ भी सत्यापित किए बिना हरी हो जाती है, उससे भी बदतर है जो विफल होती है। जॉब को `security-events: write` की आवश्यकता है, अन्यथा अपलोड 403 का उत्तर देता है। कोड स्कैनिंग के बिना रिपॉज़िटरी में `upload-sarif: false` सेट करें। ### या इसे स्वयं जोड़ें एक्शन चार चरण हैं और कोई जादू नहीं। इसे हाथ से करने में उतनी ही सावधानी लगती है जितनी लगती है। अपलोड को उन रनों पर चलना है जिनके पास रिपोर्ट है, जो वे हैं जो 0 या 1 के साथ बाहर निकले और वे नहीं जो 2 के साथ बाहर निकले, और जॉब को विफल करने वाला चरण उसके बाद आना चाहिए, अन्यथा फाइंडिंग्स उस टैब तक कभी नहीं पहुँचतीं जिस तक वे पहुँचने के लिए मौजूद हैं।```yaml permissions: # required for all workflows security-events: write # only required for workflows in private repositories actions: read contents: read steps: - name: Check captured MCP session id: check run: | code=0 mcpsnoop check --format sarif artifacts/session.jsonl > mcpsnoop.sarif || code=$? echo "exit-code=$code" >> "$GITHUB_OUTPUT" # 2 means the check never happened, so there is no report to publish and # nothing was verified. Stop here rather than uploading an empty file. [ "$code" -le 1 ] || exit 1 - name: Upload mcpsnoop SARIF report if: ${{ !cancelled() }} uses: github/codeql-action/upload-sarif@v4 with: sarif_file: mcpsnoop.sarif category: mcpsnoop - name: Fail on findings # Separate, and after the upload, so the findings reach the Security tab on # exactly the runs that have some. if: ${{ !cancelled() && steps.check.outputs.exit-code == '1' }} run: exit 1

mcpsnoop check --fail-on drift --baseline .mcpsnoop/baselines session.jsonl ``` `drift` `check` के लिए ऑप्ट-इन है। डिफ़ॉल्ट `error,invalid,warn` गेट अपरिवर्तित है। ### ऐसी सुविधा पकड़ें जिस पर किसी भी पक्ष ने बातचीत नहीं की SEP-2133 ने वैकल्पिक सुविधाओं को कोर प्रोटोकॉल से हटाकर एक्सटेंशन में स्थानांतरित कर दिया, जिन्हें प्रत्येक पक्ष की क्षमताओं के `extensions` मैप में विज्ञापित किया जाता है। Tasks उनमें से एक है, इसलिए 2026-07-28 को एक `tasks/get`, एक `notifications/tasks` या एक `tools/call` जिसका उत्तर टास्क हैंडल के साथ दिया गया है, तभी मायने रखता है जब दूसरे पक्ष ने कहा हो कि वह Tasks बोलता है। जब उसने नहीं कहा, तो स्पेक स्पष्ट है: सहायक पक्ष को या तो कोर व्यवहार पर वापस जाना होगा या अनुरोध को अस्वीकार करना होगा। इसे वैसे भी करना ही वह कारण है जिससे कोई सुविधा जुड़ी हुई दिखती है और फिर चुपचाप कुछ नहीं करती, और पाठक को इसके बजाय कुछ फ्रेम बाद में `-32601` या `-32021` मिलता है, या एक टास्क जो कभी आगे नहीं बढ़ता। mcpsnoop उस फ्रेम पर चेतावनी देता है जो एक्सटेंशन तक पहुंचा और बताता है कि किस पक्ष ने इसे कभी विज्ञापित नहीं किया।``` tool "slow" answered with a task handle uses the io.modelcontextprotocol/tasks extension, which the client never advertised ``` यह एक `warn` है, इसलिए डिफ़ॉल्ट `check` रन इसे विफल कर देता है। यह तब शांत रहता है जब कैप्चर यह नहीं दिखा पाता कि क्या बातचीत हुई थी, जो कि हैंडशेक के बाद शुरू होने वाला कैप्चर है या जिसकी क्षमताओं को आपके अपने रिडक्शन ने मिटा दिया है, और 2026-07-28 से पहले के रिवीज़न पर, जहाँ `tasks/*` कोर प्रोटोकॉल हैं और उनका उपयोग करना सही है। ### पुराने प्रोटोकॉल फीचर्स को फ़्लैग करें 2026-07-28 रिवीज़न Roots, Sampling और Logging को अप्रचलित (deprecated) करता है। वे कम से कम एक साल तक काम करते रहते हैं, इसलिए mcpsnoop उन्हें त्रुटियों के रूप में नहीं, बल्कि चिह्नित करता है। स्ट्रीम, क्षमता निरीक्षक (capability inspector) और एक्सपोर्ट सभी उन्हें फ़्लैग करते हैं, और प्रत्येक मार्कर प्रतिस्थापन का नाम बताता है। तीनों में से दो अब केवल मल्टी राउंड-ट्रिप अनुरोध के माध्यम से पहुँच योग्य हैं, जहाँ विधि का नाम फ्रेम पर ही नहीं, बल्कि सर्वर के `inputRequests` मैप के अंदर स्थित होता है। उन्हें भी फ़्लैग किया जाता है, ताकि जो सर्वर नए पैटर्न पर चला गया है, वह चुपचाप रिपोर्ट करना बंद न कर दे।```bash mcpsnoop check --fail-on deprecated session.jsonl ``` जैसे `drift`, `deprecated` भी ऑप्ट-इन है। डिफ़ॉल्ट रन में गिनती रिपोर्ट होती है और वह हरा (green) रहता है, इसलिए किसी अभी भी कानूनी deprecated फीचर का उपयोग करने वाला सत्र अपने आप CI को लाल नहीं करता। ### फ्लैग स्कीमा निर्माण जिन्हें क्लाइंट ठीक से संभाल नहीं पाते एक सर्वर पूरी तरह से मान्य हो सकता है और फिर भी एजेंट के लिए उपयोग करना कठिन हो सकता है। क्लाइंट इस बात में भिन्न होते हैं कि वे JSON Schema का कितना हिस्सा वास्तव में समर्थन करते हैं, और एक टूल जिसे मॉडल बार-बार गलत तरीके से कॉल करता रहता है, अक्सर वह टूल होता है जिसकी स्कीमा क्लाइंट की क्षमता से अधिक मांग करती है। टूल सारांश, जो `s` से खोला जाता है, में एक SCHEMA कॉलम होता है जो प्रत्येक विज्ञापित टूल की स्कीमा की सबसे उल्लेखनीय बात बताता है, और जब एक से अधिक प्रकार होते हैं तो अंत में `+` लगा होता है। | दिखाया गया | अर्थ | |---|---| | `no root` | `inputSchema` अनुपस्थित है, JSON ऑब्जेक्ट नहीं है, या इसका रूट प्रकार `"object"` के अलावा कुछ और है | | `dialect` | एक `$schema` जो 2020-12 के अलावा किसी अन्य डायलेक्ट का नाम देता है, जिसे रिवीज़न डिफ़ॉल्ट रूप से उपयोग करता है | | `ext ref` | एक `$ref` जो दस्तावेज़ के बाहर इंगित करता है, जो वह स्थिति भी है जिसके बारे में स्पेक कार्यान्वयनकर्ताओं को चेतावनी देता है कि वे आँख बंद करके उसका पालन न करें | | `oneOf`, `anyOf`, `allOf`, `not` | एक संरचना (composition) कीवर्ड, जिसे क्लाइंट्स के बीच असंगत रूप से संभाला जाता है | | `ref` | एक `$ref` जो उसी दस्तावेज़ के भीतर इंगित करता है | | `untyped` | एक प्रॉपर्टी जो कोई प्रकार घोषित नहीं करती और यह बताने का कोई अन्य तरीका नहीं देती कि वह क्या स्वीकार करती है | पहले को छोड़कर बाकी सभी निर्णय के बजाय अवलोकन हैं। `oneOf` का उपयोग करने वाली स्कीमा गलत नहीं है, केवल संभावना है कि विभिन्न क्लाइंट इसे अलग-अलग तरीके से पढ़ेंगे, और एक स्कीमा जो चाहे वह डायलेक्ट घोषित कर सकती है। `no root` अपवाद है: `Tool` परिभाषा `inputSchema` की आवश्यकता रखती है और उसके रूट प्रकार को `"object"` पर पिन करती है, इसलिए सूची को मान्य करने वाला क्लाइंट उस टूल को सीधे अस्वीकार कर देता है और वह कभी कॉल करने योग्य नहीं बनता, और वायर पर यह बताने के लिए कुछ भी नहीं होता। इसी कारण `no root` कॉलम में सबसे आगे है, और mcpsnoop की अपनी रिडक्शन द्वारा साफ की गई स्कीमा कभी रिपोर्ट नहीं की जाती, क्योंकि एक अपठनीय स्कीमा गलत स्कीमा नहीं है। यह विभाजन तय करता है कि `check` उनके साथ क्या करता है। `no root` `tools/list` फ्रेम पर एक चेतावनी है, इसलिए यह बिना किसी फ्लैग के डिफ़ॉल्ट `error,invalid,warn` गेट को विफल कर देता है, जो कि मुद्दा है: एक सर्वर जो एक अनुपयोगी टूल भेजता है, वह हर हैंडशेक का सामान्य रूप से उत्तर देता है और बस कभी `tools/call` प्राप्त नहीं करता। अवलोकनों को `schema_findings` के रूप में गिना जाता है और `schema findings:` के अंतर्गत रिपोर्ट किया जाता है, और केवल तब रन को विफल करते हैं जब आप `--fail-on` में `schema` जोड़ते हैं। दोनों `--format junit` और `--format sarif` तक पहुँचते हैं, और `export` प्रति-टूल सूची को `summary.definitions.per_tool[].findings` के अंतर्गत ले जाता है।```bash mcpsnoop check session.jsonl # a non-object root already fails this mcpsnoop check --fail-on schema session.jsonl # and now so do the observations ``` कॉलम चेतावनी रंग रखता है और कभी भी ERR कॉलम का लाल रंग नहीं दिखाता, और mcpsnoop अभी भी उस ट्रैफ़िक में कुछ भी नहीं बदलता जिसे वह आगे भेजता है। कुछ भी हल या प्राप्त नहीं किया जाता। एक बाहरी `$ref` केवल उसके रूप से पहचाना जाता है, और जिस स्कीमा की ओर वह इंगित करता है उसे कभी नहीं पढ़ा जाता। ### HTTP पर कैप्चर किए गए कॉल को दोबारा चलाएँ `r` किसी लाइव सर्वर के विरुद्ध कैप्चर किए गए कॉल को फिर से जारी करता है। stdio कैप्चर के लिए कमांड लॉग में होता है, इसलिए mcpsnoop एक अलग कॉपी लॉन्च करता है और अनुरोध उसी को भेजता है। HTTP कैप्चर में लॉन्च करने के लिए कोई कमांड नहीं होता, और जो एंडपॉइंट वह रिकॉर्ड करता है उसका userinfo और हर query मान हटा दिया जाता है, इसलिए यह सर्वर का नाम बताता है बिना डायल करने का पता होने के। इसलिए आप बताते हैं कि रीप्ले कहाँ जाता है, और mcpsnoop कभी भी प्रोडक्शन एंडपॉइंट पर डायल नहीं करता क्योंकि किसी ने एक कुंजी दबा दी।```bash mcpsnoop open --replay-target https://api.example.com/mcp session.jsonl mcpsnoop open --replay-target https://api.example.com/mcp \ --replay-header 'Authorization: Bearer sk-…' session.jsonl ``` बिना `--replay-target` के, एक HTTP सत्र यह कहता है कि ऐसा है, बजाय एक ऐसी कुंजी देने के जो काम नहीं कर सकती। इसके साथ, `r` फिर भी सत्र के पहले भेजने से पहले पूछता है, उसी तरह जैसे एक रिकॉर्ड किया गया कमांड चलाने से पहले उत्तर मांगता है। एक क्रेडेंशियल सर्वर तक `--replay-header` के माध्यम से पहुँचता है और कहीं और नहीं। mcpsnoop कोई `Authorization` हेडर रिकॉर्ड नहीं करता और कोई रीप्ले नहीं करता, इसलिए रीप्ले के लीक करने के लिए कुछ भी कैप्चर नहीं होता। रीप्ले किया गया POST वही ले जाता है जो ट्रांसपोर्ट अनिवार्य बनाता है, जो एक POST नंगे कैप्चर किए गए बॉडी के साथ नहीं करता: `MCP-Protocol-Version`, एक `Accept` जो `application/json` और `text/event-stream` दोनों को सूचीबद्ध करता है, `Mcp-Method`, `Mcp-Name` जहाँ स्पेक इसे आवश्यक बनाता है, और हर कैप्चर किया गया `Mcp-Param-*`। वे कैप्चर से शब्दशः फिर से भेजे जाते हैं, base64 सेंटिनल और सब कुछ, इसलिए वे बॉडी से उस तरह असहमत नहीं हो सकते जैसे एक पुनः-व्युत्पत्ति कर सकती है। एक हेडर जो कॉपी नहीं किया जाता वह प्रोटोकॉल संस्करण है, क्योंकि रीप्ले किया गया बॉडी उस संशोधन की घोषणा करता है जो mcpsnoop बोलता है और हेडर को बॉडी से मेल खाना पड़ता है। `Mcp-Name` कॉपी करने के बजाय भेजे जा रहे बॉडी से व्युत्पन्न होता है, क्योंकि स्पेक इसे `params.name` या `params.uri` से स्रोतित करता है और सर्वर को एक ऐसे हेडर को अस्वीकार करने की आवश्यकता होती है जो बॉडी से असहमत हो, इसलिए एक संपादन जो टूल का नाम बदलता है अन्यथा पुराना नाम भेज देगा। `Mcp-Param-*` हेडर कैप्चर किए गए तर्कों को प्रतिबिंबित करते हैं, इसलिए एक संपादित रीप्ले उनमें से कोई नहीं भेजता, बजाय किसी ऐसी चीज़ के बारे में दावा करने के जो किसी ने फिर से लिखी हो। एक कैप्चर केवल उसी परिवार में हेडर सेट कर सकता है। एक लॉग एक फ़ाइल है जिसे लोग इधर-उधर देते हैं, और इसे किसी भी हेडर का नाम देने देना उसे अनिवार्य हेडर को अधिलेखित करने या एक ऐसा क्रेडेंशियल जोड़ने देगा जो किसी ने पास नहीं किया। एक `Mcp-Param-*` जिसे एक रिडक्शन नियम ने साफ़ कर दिया है, रीप्ले को एक कारण के साथ रोक देता है। प्लेसहोल्डर भेजना mcpsnoop के अपने बाइट्स को एक लाइव सर्वर पर डाल देगा जैसे कि एक उपयोगकर्ता ने उन्हें टाइप किया हो। एक रीडायरेक्ट को फॉलो करने के बजाय अस्वीकार कर दिया जाता है। पता वही है जिसे आपने नामित किया और उत्तर दिया, और एक 307 को फॉलो करना उस विकल्प को दूर के छोर को सौंप देगा, बॉडी को फिर से भेजना और, एक हॉप पर जो केवल पोर्ट बदलता है, क्रेडेंशियल को भी। mcpsnoop रिपोर्ट करता है कि सर्वर इसे कहाँ भेजना चाहता था और आपको यह तय करने देता है कि क्या उसके बजाय उसे नामित करना है। एक उत्तर जो एक एकल JSON ऑब्जेक्ट के रूप में आता है और एक जो एक इवेंट स्ट्रीम के रूप में आता है, दोनों पढ़े जाते हैं, और एक विफलता को संख्या के बजाय नामित किया जाता है: - एक 401 उस स्कीम की रिपोर्ट करता है जो सर्वर ने मांगी - एक `-32020` रिपोर्ट करता है कि उसने किस पर आपत्ति जताई - एक गैर-JSON-RPC 400 या 404 कहता है कि पता इस संशोधन का एक Streamable HTTP एंडपॉइंट नहीं है ### सर्वर की विलंबता को उपयोगकर्ता की विलंबता से अलग बताएँ मल्टी राउंड-ट्रिप अनुरोधों के तहत एक टूल कॉल कई अनुरोध होते हैं, और वे सेकंड जो एक व्यक्ति ने एक पूछताछ का उत्तर देने में बिताए, उस अवधि के अंदर बैठते हैं। यह जानबूझकर है, क्योंकि वह अंतराल आमतौर पर वही होता है जिसे आप सबसे अधिक देखना चाहते हैं, लेकिन इसका मतलब है कि एक संख्या दोनों प्रश्नों का उत्तर नहीं दे सकती। एक `book_flight` श्रृंखला पर जहाँ सर्वर ने 1.2 सेकंड काम किया जबकि उपयोगकर्ता ने 37 लिए, `check --max-duration 5s` टूल को 38.2 सेकंड के लिए दोषी ठहराता है। यह फिर भी करता है, क्योंकि उस फ्लैग का अर्थ बदलना हर पाइपलाइन को ढीला कर देगा जो पहले से ही इसे सेट करती है। दो सहोदर उसका नाम देते हैं जो वे मापते हैं।```bash mcpsnoop check --max-server-duration 1s session.jsonl # the server's share alone mcpsnoop check --max-round-trips 2 session.jsonl # how chatty a tool is ``` सुरक्षा अनुसंधानकर्ताओं और पेन-टेस्टर्स के लिए, यह उपकरण एक व्यावहारिक समाधान प्रदान करता है जो मौजूदा वर्कफ़्लो में सहजता से एकीकृत हो जाता है। इसका मॉड्यूलर आर्किटेक्चर विशिष्ट आवश्यकताओं के अनुसार अनुकूलन की अनुमति देता है, जबकि व्यापक दस्तावेज़ीकरण सुनिश्चित करता है कि उपयोगकर्ता इसकी पूरी क्षमता का लाभ उठा सकें। चाहे आप स्वचालित स्कैनिंग, लॉग विश्लेषण, या वास्तविक समय की निगरानी से निपट रहे हों, यह उपकरण आपके सुरक्षा ढांचे में एक मूल्यवान अतिरिक्त साबित होता है।``` assertion failed: 1 tool call exceeded the 1s server budget (worst: tool "book_flight" held for 1.2s) assertion failed: 1 tool call exceeded the 2 round trip budget (worst: tool "book_flight" took 3) ``` दोनों डिफ़ॉल्ट रूप से बंद हैं, इसलिए एक डिफ़ॉल्ट `check` रन प्रभावित नहीं होता, और दोनों फ्रेम टाइमस्टैम्प और एक लिंक से पढ़े जाते हैं जिसे mcpsnoop पहले ही अनुमानित कर चुका है, इसलिए कोई भी इरादे का अनुमान नहीं लगाता। TUI में ब्रेकडाउन के लिए `i` दबाएँ, या json, text और html एक्सपोर्ट में `interactions` पढ़ें। प्रत्येक प्रविष्टि एक तार्किक ऑपरेशन है जिसमें उसकी राउंड ट्रिप गिनती, उसका कुल समय, सर्वर ने उसे कितने समय तक अपने पास रखा और वह कितने समय तक क्लाइंट की प्रतीक्षा कर रहा था, साथ ही एक प्रति-हॉप पंक्ति जो बताती है कि प्रत्येक उत्तर ने क्या माँगा। प्रति-टूल सारांश में एक `TRIPS` कॉलम जुड़ जाता है ताकि एक बातूनी टूल बिना कुछ खोले दिखाई दे। `export --format har` सर्वर के हिस्से को `wait` में और बाकी को `blocked` में रखता है, जो उस फ़ील्ड का उद्देश्य है, ताकि एक व्यूअर 38-सेकंड का सर्वर प्रतीक्षा दिखाना बंद कर दे जो कभी हुई ही नहीं। गिनती और दोनों हिस्से फ्रेम आने पर जमा होते हैं, न कि जब आप पूछते हैं तब प्राप्त होते हैं, क्योंकि लाइव स्टोर अपने बजट के भीतर रहने के लिए पुराने फ्रेम जारी करता है और एक व्युत्पन्न उत्तर चुपचाप एक श्रृंखला के बजाय एक विंडो होता। प्रति-हॉप ब्रेकडाउन अभी भी रखे गए फ्रेम से पढ़ा जाता है, और यह तब कहता है जब यह केवल उसका एक हिस्सा होता है। `ServerTime + ClientTurnaround` कुल के बराबर होता है निर्माण के आधार पर, न कि किसी ऐसे अंकगणित से जिस पर किसी को भरोसा करना पड़े। `--max-round-trips` एक ऐसी श्रृंखला का न्याय करता है जो अभी भी चल रही है, क्योंकि हर अनुरोध जो उसने पहले ही किया है वह गिनने योग्य है और एक सर्वर जो बार-बार पूछता है वह ठीक वही ऑपरेशन उत्पन्न करता है जिसे कोई कभी पूरा नहीं करता। `--max-server-duration` एक समाप्ति की प्रतीक्षा करता है, जो वही नियम है जो `--max-duration` पहले से लागू करता है, क्योंकि एक ऑपरेशन जो अभी भी खुला है उसके पास न्याय करने के लिए कोई विलंबता नहीं है। एक ऑपरेशन जिसे mcpsnoop लिंक नहीं कर सका, वह अपनी स्वयं की एकल-हॉप प्रविष्टि बना रहता है। `matchRetry` जानबूझकर एक अस्पष्ट लिंक को अस्वीकार करता है, और यह दृश्य उस अंतर को नहीं भरता। एक ऑपरेशन जिसमें एक अनुरोध लगा, उसमें कोई हॉप ब्रेकडाउन नहीं होता, क्योंकि एक एकल हॉप ऊपर के कुलों को शब्द-दर-शब्द दोहराता है। एक श्रृंखला प्रति अनुरोध एक हॉप की रिपोर्ट करती है, और यह तब कहती है जब स्टोर अब हर फ्रेम नहीं रखता या जब काम अनुरोध और उत्तर जोड़ी से अलग होकर तय हो गया, जिससे एक हॉप बनता है, जो एक टास्क हैंडल करता है। ### देखें कि सर्वर ने आपके उपयोगकर्ता से क्या माँगा Elicitation MCP में एकमात्र मार्ग है जहाँ एक व्यक्ति सर्वर में डेटा टाइप करता है, और MRTR के तहत प्रश्न और उत्तर अब एक आदान-प्रदान के दो हिस्से नहीं रह गए हैं। प्रश्न एक `InputRequiredResult` में दबा हुआ है, उत्तर एक अलग id के तहत एक रीट्राई पर `inputResponses` के अंदर वापस आता है, और एकमात्र चीज़ जो उन्हें जोड़ती है वह लिंक है जिसे mcpsnoop पहले ही अनुमानित कर चुका है। उस जोड़ी के बिना एक अस्वीकृत पासवर्ड अनुरोध एक साधारण टूल त्रुटि जैसा पढ़ा जाता है।``` tools/call login_legacy [form] creds: decline after 3s password string ``` TUI में `l` दबाएँ, या json, text और html एक्सपोर्ट में `elicitations` पढ़ें। हर पंक्ति उस ऑपरेशन का नाम देती है जिसे प्रश्न ने बाधित किया, मोड, संदेश, क्या माँगा गया था, उपयोगकर्ता ने क्या किया और उन्होंने कितना समय लिया। एक प्रश्न जिसका कोई भी retry कभी उत्तर नहीं दे पाया, pending के रूप में दिखता है, जिसे MRTR एक सामान्य परिणाम बनाता है न कि त्रुटि, क्योंकि spec सर्वरों को बताता है कि वे यह न मानें कि कोई क्लाइंट बिल्कुल retry करेगा। Form पंक्तियाँ `requestedSchema` प्रॉपर्टी नाम और उनके घोषित प्रकार सूचीबद्ध करती हैं। एक प्रॉपर्टी जिसके subschema को किसी redaction नियम ने बदल दिया है, वह placeholder के बजाय एक अज्ञात प्रकार दिखाती है, क्योंकि placeholder ऐसी चीज़ नहीं है जिसे सर्वर ने घोषित किया हो। URL पंक्तियाँ पता पूरा रखती हैं, जिसे spec क्लाइंट को consent से पहले दिखाने के लिए कहता है, और होस्ट को अलग से नाम देती हैं, जिसे वह subdomain spoofing के खिलाफ highlight करने के लिए कहता है। Ledger कभी भी कोई submitted मान नहीं रखता। उपयोगकर्ता ने जो टाइप किया वह capture में रहता है जिसे जिसे भी ज़रूरत हो, और इसे एक सारांश सतह से बाहर रखना जो export और paste करने के लिए बनाई गई है, यही इसे redaction कहानी से पूरी तरह बाहर रखता है। यह url मोड में सबसे अधिक मायने रखता है, जहाँ spec जानबूझकर credentials रखता है। एक retry उसी round का उत्तर देता है जिससे वह जारी किया गया था, और किसी और का नहीं। MRTR एक सर्वर को बताता है कि जब कोई क्लाइंट कुछ माँगी गई चीज़ों को छोड़ देता है, तो उसे एक नए round में फिर से पूछना चाहिए, इसलिए एक पुराना round जिसमें एक अनुत्तरित key एक उत्तरित key के साथ हो, सामान्य ट्रैफ़िक है, और अनुत्तरित आधा pending रहता है, बाद के round के उत्तर को उधार लेने के बजाय। एक दर्ज प्रश्न सीमित है। संदेश, url और फ़ील्ड सूची session के जीवन के लिए रखी जाती हैं, उस frame बजट के बाहर जो bodies को जारी करता है, इसलिए एक सर्वर किसी एक को मनमाने ढंग से महंगा नहीं बना सकता। सीमाएँ किसी भी वास्तविक प्रश्न से कहीं ऊपर हैं और एक छोटा संदेश कहता है कि उसे छोटा किया गया था। यहाँ कुछ भी चेतावनी नहीं देता और कुछ भी `check` exit code नहीं बदलता। एक ledger रिकॉर्ड करता है कि क्या हुआ। यह उसका निर्णय नहीं करता। ### उस टूल को खोजें जो चार में से एक बार विफल होता है `check` एक session पढ़ता है और `diff` ठीक दो पढ़ता है, इसलिए एक टूल जो कभी-कभी विफल होता है, तब तक अदृश्य रहता है जब तक कोई captures को हाथ से नहीं खोलता। एक सर्वर के सोलह captures के दौरान जिसका `run_query` लगभग एक चौथाई समय `isError` का उत्तर देता है, `check` सबसे नया, ईमानदारी से, clean के रूप में रिपोर्ट करता है।```bash mcpsnoop stats mcpsnoop stats --since 7d --label prod mcpsnoop stats --limit 20 --format json ``` मैं आपकी मदद करने के लिए यहाँ हूँ, लेकिन आपने कोई इनपुट प्रदान नहीं किया है। कृपया वह Markdown सामग्री साझा करें जिसे आप अनुवाद करना चाहते हैं, और मैं इसे हिंदी में अनुवाद कर दूंगा।``` read 16 logs of 16 in ~/.local/state/mcpsnoop/sessions SERVER TOOL CALLS ERR PROTO FAIL% SESS p50 p95 p99 DEF flaky-demo run_query 13 3 0 23.1% 3/13 434ms 519ms 519ms 195B docs-mirror run_query 3 1 0 33.3% 1/3 357ms 434ms 434ms 195B docs-mirror search_docs 12 0 0 0.0% 0/3 377ms 386ms 386ms 200B flaky-demo search_docs 52 0 0 0.0% 0/13 42ms 58ms 59ms 200B ``` `ERR` और `PROTO` अलग-अलग कॉलम हैं क्योंकि विनिर्देशन उन्हें अलग-अलग चीज़ें बनाता है। एक उपकरण जो `isError` का उत्तर देता है, वह किसी ऐसी चीज़ की रिपोर्ट कर रहा है जिस पर एक मॉडल कार्रवाई कर सकता है और पुनः प्रयास कर सकता है। एक JSON-RPC त्रुटि अनुरोध या सर्वर के गलत होने का मामला है। `SESS` उन सत्रों की संख्या है जिन्होंने विफलता देखी, उन सत्रों के मुकाबले जिन्होंने उपकरण को कॉल किया, जो "दस में एक रन" का प्रश्न है जिसका उत्तर कॉल पर आधारित दर नहीं दे सकती। पंक्तियाँ सर्वर और लेबल को एक साथ कुंजी के रूप में उपयोग करती हैं। सर्वर stdio के लिए दर्ज किया गया कमांड और कार्यशील निर्देशिका है और HTTP के लिए एंडपॉइंट है, वही पहचान जो `inventory` उपयोग करता है। अकेले कोई भी आधा ऐसी चीज़ को एकत्र करता है जिसे नहीं करना चाहिए: अकेला लेबल दो सर्वरों को मिला देता है जो एक नाम प्राप्त करते हैं, जो तब होता है जब किसी प्रोजेक्ट के दो चेकआउट एक ही एंट्री पॉइंट चलाते हैं, और अकेली पहचान एक कमांड को मिला देती है जिसे जानबूझकर `prod` के रूप में और फिर `staging` के रूप में चलाया गया। दोनों गलतियाँ दो साफ वितरणों को एक ऐसे वितरण में मिला देती हैं जो किसी का भी वर्णन नहीं करता। जब दो पंक्तियाँ वास्तव में एक लेबल साझा करती हैं, तो `SERVER` सेल कार्यशील निर्देशिका या एंडपॉइंट रखता है जो उन्हें अलग बताता है, और JSON हर पंक्ति पर `command`, `cwd` और `endpoint` रखता है। एक नाम जो कभी अस्पष्ट नहीं था, उसे वैसे ही छोड़ दिया जाता है, इसलिए सामान्य तालिका अपरिवर्तित रहती है। लॉग में हर सत्र मोड़ा जाता है, केवल पहला नहीं, इसलिए कैटेनेटिंग कैप्चर द्वारा बनाई गई फ़ाइल उन सभी की गिनती करती है। प्रतिशतक कच्ची अवधियों पर एकत्र किए जाते हैं। माध्यिकाओं का माध्यिका किसी चीज़ का माध्यिका नहीं है। एक बहु-राउंड ट्रिप ऑपरेशन एक कॉल है जिसकी एक अवधि है, चाहे उसमें कितने भी अनुरोध लगे हों, और एक कॉल जो अभी भी खुली है, `CALLS` में गिना जाता है जबकि कोई विलंबता योगदान नहीं करता। एक समय में एक कैप्चर मेमोरी में रहता है। एक लॉग लोड किया जाता है, चालू काउंटरों में मोड़ा जाता है, और अगले के खुलने से पहले छोड़ दिया जाता है, इसलिए सैकड़ों की निर्देशिका की लागत सबसे बड़े एकल कैप्चर के बराबर होती है, उनके योग के नहीं। `--limit` डिफ़ॉल्ट रूप से सबसे नए लॉग में से सौ लेता है और हेडर बताता है कि कितने में से कितने पढ़े गए, इसलिए एक सीमित उत्तर कभी भी पूर्ण उत्तर के रूप में नहीं गुजरता। `stats` रिपोर्ट करता है और रोकता नहीं: यह कुछ नहीं लिखता, कोई बेसलाइन नहीं छूता, कोई सॉकेट नहीं खोलता, और जब भी वॉक सफल होता है तो 0 के साथ बाहर निकलता है। ### देखें कि यहाँ वास्तव में कौन से सर्वर चले हैं Shadow MCP के बारे में लोग जो खोज दोहराते रहते हैं, वह यह है कि संगठनों को किसी भी अनुमोदित सर्वर से कई गुना अधिक चल रहे MCP सर्वर मिलते हैं, क्योंकि एक सर्वर अक्सर सिर्फ एक निर्भरता होती है जिसे किसी ने IDE प्लगइन में जोड़ा। वही बात एक लैपटॉप पर लघु रूप में होती है, और mcpsnoop पूरे समय उत्तर रिकॉर्ड करता रहा है बिना उसे कभी दिखाए।```bash mcpsnoop inventory mcpsnoop inventory --tools # also count what each server last advertised mcpsnoop inventory --format json # for something else to read ``` प्रति सत्र के बजाय प्रति सर्वर एक पंक्ति। पंक्ति कुंजी रिकॉर्ड किया गया कमांड और कार्यशील निर्देशिका है, लेबल कभी नहीं, क्योंकि लेबल कमांड के अंतिम पथ तत्व से आता है और `node ~/one/build/index.js` और `node ~/two/build/index.js` दोनों `index.js` व्युत्पन्न करते हैं। एक HTTP सत्र उस एंडपॉइंट पर कुंजी रखता है जिसे उसने प्रॉक्सी किया था, क्योंकि mcpsnoop ने वहाँ कुछ भी लॉन्च नहीं किया। पढ़ना प्रति लॉग एक लिफाफा है, मेटा फ्रेम जो प्रॉक्सी पहले लिखता है, इसलिए यह बड़े कैप्चर की निर्देशिका पर सस्ता रहता है। `--tools` अपवाद है और प्रति सर्वर एक लॉग पढ़ता है, प्रत्येक का सबसे हालिया रन, यही कारण है कि यह एक फ्लैग है बजाय एक कॉलम के। फिर भी पढ़ना सीमित है, क्योंकि एक टूल इन्वेंट्री सत्र स्थिति है जिसे स्टोर आगे बढ़ते हुए मोड़ता है, इसलिए एक सौ-मेगाबाइट कैप्चर एक निश्चित विंडो के माध्यम से पढ़ा जाता है बजाय एक पूर्णांक उत्पन्न करने के लिए पूरा रखे जाने के। जब कोई गिनती नहीं होती है तो पंक्ति कहती है कि तीन चीजों में से कौन सी हुई, क्योंकि एक लॉग जिसे पढ़ा नहीं जा सका वह एक सर्वर नहीं है जिसने कुछ भी विज्ञापित नहीं किया, और दोनों के लिए एक वाक्य mcpsnoop को कुछ झूठा बताएगा। एक कमांड जिसे `--redact` नियम ने फिर से लिखा है उसे रिकॉर्ड किए अनुसार मुद्रित और चिह्नित किया जाता है, बजाय उस कमांड के रूप में पारित किए जाने के जो चला। एक सर्वर के दो रन, एक साफ़ किया गया और एक नहीं, दो पंक्तियाँ हैं। mcpsnoop यह नहीं जान सकता कि प्लेसहोल्डर ने क्या बदला, और उन्हें मर्ज करने का मतलब यह अनुमान लगाना होगा कि छिपे हुए हिस्से मेल खाते थे। एक सर्वर दो `--label` मानों के तहत चला वह एक पंक्ति है जो दोनों नाम रखती है, क्योंकि कुंजी कमांड है नाम के बजाय। एक पंक्ति में कुछ भी mcpsnoop द्वारा नहीं लिखा गया है। एक कमांड उस व्यक्ति से आता है जिसने सर्वर स्थापित किया, एक कार्यशील निर्देशिका फाइलसिस्टम से आती है, और एक व्युत्पन्न लेबल कमांड से आता है। एक मान जिसमें नियंत्रण वर्ण है उसे कच्चा मुद्रित करने के बजाय उद्धृत किया जाता है, इसलिए एक निर्देशिका जिसके नाम में न्यूलाइन है वह उस फ़ील्ड को बंद नहीं कर सकती जिसमें इसे मुद्रित किया गया है और निम्नलिखित पंक्तियों को ऐसे सर्वर के रूप में पढ़ा जा सकता है जो कभी नहीं चले। एक तर्क जिसमें स्थान है उसे भी उद्धृत किया जाता है, क्योंकि `node "~/My Project/ build/index.js"` अन्यथा दो तर्कों से अप्रभेद्य है। वॉक जो कुछ भी मोड़ नहीं सका उसे हेडर में नामित किया जाता है बजाय छोड़े जाने के। खाली लॉग क्षतिग्रस्त लोगों से अलग गिने जाते हैं, क्योंकि एक शून्य-बाइट लॉग एक रन का सामान्य अवशेष है जिसका exec विफल रहा या एक HTTP प्रॉक्सी जिसे किसी ने नहीं बुलाया। आउटपुट को हाल की तारीख के बजाय नाम से क्रमबद्ध किया जाता है ताकि एक निर्देशिका पर दो रन समान बाइट्स उत्पन्न करें, जो इसे बाद में डिफ करने के लिए बेसलाइन के रूप में उपयोग करने योग्य बनाता है। दो अंतराल निर्माण द्वारा हैं बजाय अनदेखी के। एक रन जिसमें `--trace-file` था उसने सत्र निर्देशिका के बाहर लिखा और दिखाई नहीं देगा, और `prune` लॉग हटाता है, इसलिए पहली बार देखा गया केवल उतना ही पुराना है जितना अभी भी डिस्क पर है। mcpsnoop रिपोर्ट करता है कि इस मशीन पर इसके माध्यम से क्या चला। यह कोई नेटवर्क स्कैन नहीं करता, कोई क्लाइंट कॉन्फ़िग नहीं पढ़ता जिस पर इसे इंगित नहीं किया गया था, और कुछ भी न्याय नहीं करता। ### एक टूटे हुए सर्वर को एक ऐसे टूल से बताएं जो ना कहता है एक टूल जो `result.isError` का उत्तर देता है वह काम कर रहा है। उसने देखा और कुछ नहीं पाया, या उसने इनपुट अस्वीकार कर दिया। एक सर्वर जो JSON-RPC त्रुटि का उत्तर देता है वह टूटा हुआ है। दोनों एक संख्या थे टूल सारांश में, जिसका मतलब था कि एक अच्छा व्यवहार करने वाला टूल जो डोमेन विफलताओं की रिपोर्ट करता है बिल्कुल एक टूटे हुए सर्वर जैसा दिखता था, और उसके ऊपर क्रमबद्ध होता था। `ERR` कॉलम उन्हें अलग करता है। लाल सर्वर पक्ष है, जो एक JSON-RPC त्रुटि है या एक कार्य जो बिना कारण बताए विफल समाप्त हुआ। चेतावनी रंग टूल का अपना `isError` है। एक टूल जिसमें दोनों हैं वह जुड़ी हुई गिनती दिखाता है, लाल पहले, और एक तालिका के नीचे की पंक्ति दो कुलों का नाम देती है जब भी समझाने के लिए एक चेतावनी संख्या होती है। निर्यात वही विभाजन रखता है जैसे `protocol_errors` और `tool_errors` `errors` कुल के बगल में जिसमें वे हमेशा जुड़ते हैं। `check --fail-on error` अपरिवर्तित है और अभी भी दोनों पर फायर करता है, क्योंकि एक गेट जो उनमें से एक को अनदेखा करता है वह एक गेट होगा जिसे एक सर्वर दूसरे को लौटाकर बंद कर सकता है।```bash mcpsnoop export -T json | jq '.summary.tools[] | {name, errors, protocol_errors, tool_errors}' ``` ### देखें कि सर्वर आपको संदर्भ में कितना खर्च करता है टूल परिभाषाएँ हर वार्तालाप में मॉडल के संदर्भ में प्रवेश करती हैं, और टूल परिणाम हर कॉल पर। टूल सारांश (`s`) दोनों को उस सत्र से मापता है जिसे आपने वास्तव में कैप्चर किया था। `definitions` पंक्ति निश्चित लागत है: इस सर्वर का `tools/list` एक भी कॉल किए जाने से पहले कितना वजन रखता है। `DEF` कॉलम उसे प्रति टूल तोड़ता है और `RESULT` वह है जो अब तक प्रत्येक टूल के उत्तरों की लागत रही है। तालिका त्रुटियों और विलंबता के अनुसार क्रमबद्ध रहती है, इसलिए महंगी परिभाषाओं को खोजने के लिए `DEF` को स्कैन करें। निर्यात उन्हें सबसे भारी पहले सूचीबद्ध करता है। तालिका के नीचे एक पंक्ति सबसे भारी परिणाम का नाम बताती है, जिसे कुल योग छिपा देता है। परिभाषा आंकड़े महत्वहीन व्हाइटस्पेस हटाए गए JSON हैं, इसलिए एक सर्वर जो अपने `tools/list` को प्रिटी-प्रिंट करता है, उसे उस सर्वर से अधिक महंगा नहीं गिना जाता जो नहीं करता, और वही सर्वर कैप्चर के बीच समान मापता है। `RESULT` वे बाइट्स हैं जैसे वे आए: एक परिणाम एक एकमुश्त पेलोड है, न कि एक अनुबंध जो सामान्यीकरण के लायक हो।```bash mcpsnoop export -T json | jq '.summary.definitions' ``` निर्यात में समान आँकड़े होते हैं, प्रति टूल और विवरण तथा स्कीमा बाइट्स में विभाजित, इसलिए एक मोटा विवरण और एक मोटी स्कीमा अलग-अलग रहते हैं और दोनों को कैप्चर के बीच ट्रैक किया जा सकता है। `mcpsnoop diff` आपको बताता है कि दो सत्रों के बीच विवरण या स्कीमा बदल गया है। निर्यात वह जगह है जहाँ उस परिवर्तन का आकार रहता है। **ये बाइट्स हैं, टोकन नहीं।** टोकन गिनती मॉडल पर निर्भर करती है, इसलिए इसे मापने का मतलब एक टोकनाइज़र शिप करना और किसी का चयन करना होगा। बाइट्स सटीक हैं और आप अपना स्वयं का अनुपात लागू कर सकते हैं। एक अधूरा `tools/list` रिपोर्ट करता है कि उसने न्यूनतम सीमा के रूप में क्या देखा और ऐसा कहता है, बजाय आंशिक योग को कुल के रूप में पेश करने के। ### एक क्लाइंट का पता लगाएँ जो सर्वर स्थिति को खराब करता है ``` --- [Read more](https://github.com/kerlenton/mcpsnoop)

फ़्लैग	विफल होता है जब
`--max-duration <dur>`	एक या अधिक पूर्ण टूल कॉल ने बजट पार कर लिया, उनकी गिनती और सबसे खराब कॉल की रिपोर्ट करते हुए
`--expect-tool <name>`	नामित टूल को कभी कॉल नहीं किया गया (दोहराने योग्य)
`--forbid-tool <name>`	नामित टूल को कॉल किया गया (दोहराने योग्य)

नियम	के रूप में रिपोर्ट किया गया
क्लाइंट को `application/json` और `text/event-stream` दोनों को सूचीबद्ध करने वाला `Accept` भेजना चाहिए	अनुरोध पर `warn`
JSON-RPC अनुरोध का उत्तर देने वाले सर्वर को `Content-Type: application/json` या `text/event-stream` लौटाना चाहिए	प्रतिक्रिया पर `warn`

विकल्प	विवरण	डिफ़ॉल्ट
`--threads`	उपयोग करने के लिए थ्रेड्स की संख्या	10
`--timeout`	अनुरोधों के लिए टाइमआउट (सेकंड में)	30
`--verbose`	विस्तृत आउटपुट सक्षम करें	असत्य

mcpsnoop

सबसे लोकप्रिय

CI में

कॉन्फ़िग फ़ाइल

Go```bash

शेल कम्प्लीशन

यह कैसे काम करता है

सत्र निर्यात करना

Redaction

सत्रों की तुलना करना

वह दावा करें जो होना चाहिए और जो नहीं होना चाहिए

a contract for the run: search must run, delete must not, nothing over 2s

GitHub Action

ऐसे रूटिंग हेडर को पकड़ें जो बॉडी से मेल नहीं खाता

स्पेक द्वारा अनिवार्य बनाए गए ट्रांसपोर्ट हेडर की जाँच करें

टूल परिभाषा ड्रिफ्ट का पता लगाएं

वैकल्पिक निर्भरताएँ

उपयोग

बुनियादी उपयोग

उन्नत विकल्प

उदाहरण

कॉन्फ़िगरेशन

योगदान

लाइसेंस