वास्तविक उपयोग के लिए, अपने सर्वर को अपने क्लाइंट के MCP config में लपेटें।```json
{
  "mcpServers": {
    "my-server": {
      "command": "mcpsnoop",
      "args": ["--", "node", "build/index.js"]
    }
  }
}

`wrap` `claude_desktop_config.json` ढूंढता है, पहली बार इसे
`claude_desktop_config.json.mcpsnoop.bak` में कॉपी करता है, और केवल उस
एक सर्वर की प्रविष्टि को फिर से लिखता है, ताकि आपकी फ़ॉर्मेटिंग और बाकी हर सर्वर वैसे ही रहें।
फिर से लिखी गई प्रविष्टि के अंदर कुंजियाँ वर्णानुक्रम में वापस आ जाती हैं। `unwrap`
फ़ाइल को पुनर्स्थापित करता है, और जब कोई सर्वर अब wrapped न रहे तो बैकअप हटा देता है।
इनमें से किसी के बाद भी Claude Desktop को पुनः आरंभ करें, क्योंकि MCP सर्वर
स्टार्टअप पर एक बार लॉन्च होते हैं।

फिर अपने क्लाइंट का उपयोग हमेशा की तरह करें और UI खोलें।```bash
mcpsnoop

हर प्रतिक्रिया की HTTP स्थिति स्ट्रीम में दिखाई देती है, इसलिए जिस प्रतिक्रिया में अपना कोई JSON-RPC संदेश नहीं होता, वह फिर भी कुछ न होने के बजाय एक दृश्यमान फ्रेम होती है: 401 चैलेंज, अस्वीकृत Origin पर 403, 202 जो किसी notification की पावती देता है, और 502 जब लक्ष्य तक बिल्कुल नहीं पहुँचा जा सकता। 401 का `WWW-Authenticate` हेडर यथावत रखा जाता है और इंस्पेक्टर में दिखाया जाता है, क्योंकि यह auth scheme और आगे जाने हेतु resource metadata का नाम बताता है। TUI में `status:401` से स्थिति के अनुसार फ़िल्टर करें, या किसी भी विफलता के लिए `status:err` का उपयोग करें। कोई 4xx या 5xx त्रुटि मानी जाती है, इसलिए डिफ़ॉल्ट `mcpsnoop check` रन उस पर विफल हो जाता है।

अपना कोई सर्वर नहीं है? अपने स्वयं के client द्वारा संचालित, एक प्रकाशित test server के विरुद्ध [वास्तव में इसे आज़माएँ](https://github.com/kerlenton/mcpsnoop/blob/HEAD/docs/TRY_IT.md)। किसी सत्र का घटित होने के बाद निरीक्षण करने के लिए, [लॉग्स से पिछले सत्रों की समीक्षा](https://github.com/kerlenton/mcpsnoop/blob/HEAD/docs/POST_MORTEM.md) देखें।

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

यदि आप किसी project में समान shim flags का पुनः उपयोग करते हैं, तो उन्हें वर्तमान कार्यशील निर्देशिका में `.mcpsnoop.toml` फ़ाइल में रखें।```toml
label = "filesystem"
trace-file = "trace.jsonl"
redact-secrets = true
redact-key = "token,authorization"
redact-value = "sk-[A-Za-z0-9]+"
redact-path = "$.params.arguments.password"
no-trace = false

### Homebrew```bash
brew install mcpsnoop

`--older-than` आवश्यक है (कोई डिफ़ॉल्ट नहीं है जो कुछ भी हटा दे) और यह `30d` जैसी दिनों की संख्या या `72h` जैसी Go अवधि स्वीकार करता है। टूल बेसलाइन को अछूता छोड़ दिया जाता है, क्योंकि बेसलाइन सत्र के बजाय सर्वर लेबल के आधार पर होती है।

क्योंकि यह वास्तविक पाइप में बैठता है, Inspector की तरह किनारे पर नहीं, यह ठीक वही देखता है जो आपका वास्तविक क्लाइंट और सर्वर एक-दूसरे से कहते हैं, चाहे सर्वर किसी भी भाषा में लिखा गया हो।

## कीबाइंडिंग

| कुंजी | क्रिया | | कुंजी | क्रिया |
|---|---|---|---|---|
| `enter` | निरीक्षण करें / अंदर जाएं | | `/` | फ़िल्टर करें |
| `esc` | वापस | | `:` | कमांड |
| `j` / `k` | नेविगेट करें | | `r` | कॉल दोबारा चलाएँ |
| `g` / `G` | ऊपर / नीचे | | `c` | क्षमताएँ |
| `ctrl-f` / `ctrl-b` | पेज | | `s` | टूल सारांश |
| `p` | रोकें | | `y` | कॉपी करें |
| `shift`+`<key>` | कॉलम के अनुसार क्रमबद्ध करें | | `e` | निर्यात करें |
| `ctrl-d` | सत्र हटाएँ | | `f` | अनुसरण करें |
| `?` | सहायता | | | |

पूरी सूची के लिए ऐप में `?` दबाएँ।

## स्ट्रीम को फ़िल्टर करना

किसी सत्र में `/` दबाएँ और स्पेस-सेपरेटेड टोकन को AND के साथ जोड़ें। सादा टेक्स्ट method, tool, id और payload से मेल खाता है।

| टोकन | फ़िल्टर का आधार | उदाहरण |
|---|---|---|
| `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)

| Format | आपको क्या मिलता है |
|---|---|
| `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 की ओर इंगित करके spans भेजें
ट्रेसेस एंडपॉइंट पर। कलेक्टर प्रमाणीकरण या टेनेंट
हेडर के लिए `--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` पास करें: यह गैर-शून्य कोड के साथ बाहर निकलता है जब after
सत्र किसी टूल को हटाता है, टूल विवरण, शीर्षक, input schema, output
schema या एनोटेशन बदलता है, किसी कॉल की स्थिति खराब हो जाती है, या धीमा हो जाता है।
सुधार (जोड़े गए टूल्स, ठीक किए गए कॉल्स, गति वृद्धि) फिर भी शून्य कोड के साथ बाहर निकलते हैं, और आइकन
परिवर्तन भी ऐसा ही करता है, जो टूल के दिखने के तरीके को बदलता है बिना उसके कार्य को बदले।

## CI में सत्रों की जाँच करना

किसी रिकॉर्ड किए गए एजेंट रन को त्रुटियों, स्ट्रीम भ्रष्टाचार, प्रोटोकॉल चेतावनियों,
routing-header बेमेल, उन कॉल्स जिन्हें कभी प्रतिक्रिया नहीं मिली, गिराए गए फ्रेम्स जो
कैप्चर को अधूरा छोड़ देते हैं, टूल-परिभाषा विचलन, या अप्रचलित (deprecated)
प्रोटोकॉल सुविधाओं के उपयोग पर गेट करें।```bash
mcpsnoop check [--format text|junit|sarif] [--fail-on error,invalid,warn,mismatch,pending,late-result,drift,deprecated,incomplete,schema] [session-id|log.jsonl|-]

ड्रॉप किए गए फ्रेम की गिनती भी आर्टिफैक्ट्स के साथ यात्रा करती है, इसलिए एक कैप्चर जो
खुद को कम दर्शाता है, वह जहाँ भी खोला जाता है वहाँ यह बताता है: JSON
एक्सपोर्ट में `missing_frames`, HAR में `log.comment`, और OTLP में
`mcpsnoop.session.missing_frames` रिसोर्स एट्रिब्यूट।```bash
mcpsnoop check build-agent
mcpsnoop check --fail-on error,invalid artifacts/session.jsonl
mcpsnoop check --fail-on mismatch gateway-run.jsonl

### इसे वहाँ रिपोर्ट करें जहाँ CI पहले से देखता है

`--format junit` प्रत्येक सिग्नल और सत्र के लिए एक `<testcase>` लिखता है, और इसकी विफलताएँ टेक्स्ट आउटपुट के समान `--fail-on` चयन का पालन करती हैं।```yaml
- name: Check captured MCP session
  run: |
    mkdir -p test-results
    mcpsnoop check --format junit artifacts/session.jsonl > test-results/mcpsnoop.xml
- name: Upload mcpsnoop JUnit report
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: mcpsnoop-junit
    path: test-results/mcpsnoop.xml

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

स्ट्रीमेबल-HTTP ट्रांसपोर्ट पर एक गेटवे `Mcp-Method` और `Mcp-Name` के आधार पर रूट करता है, जबकि सर्वर बॉडी पढ़ता है, इसलिए एक हेडर जो बॉडी से मेल नहीं खाता, इसका मतलब है कि दोनों दो अलग-अलग अनुरोधों को देख रहे हैं। `mismatch` सिग्नल इस स्थिति, एक ऐसे बैच से जुड़ा हेडर जिसे वह संबोधित नहीं कर सकता, और एक आवश्यक हेडर के पूरी तरह से गायब होने को कवर करता है।

2026-07-28 में, एक लापता रूटिंग हेडर एक सत्यापन विफलता है, और एक अनुरूप सर्वर अनुरोध को `400` और `-32020` के साथ अस्वीकार कर देता है। mcpsnoop इसे केवल तभी रिपोर्ट करता है जब सत्र उस संशोधन या उससे बाद के संशोधन का समर्थन करता है, क्योंकि पहले के संशोधन इन हेडरों को बिल्कुल परिभाषित नहीं करते हैं और वहाँ उन्हें छोड़ देना सही है। सर्वर की अपनी `-32020` अस्वीकृति भी उसी सिग्नल के रूप में गिनी जाती है।

ऐसा नाम या संसाधन URI जो HTTP फ़ील्ड मान में फिट नहीं होगा, `=?base64?…?=` सेंटिनल में Base64 रूप में यात्रा करता है, जिसे तुलना से पहले डिकोड किया जाता है, इसलिए जो क्लाइंट सही ढंग से एन्कोड करता है, उसे कभी फ़्लैग नहीं किया जाता।

HTTP `tools/call` अनुरोधों पर mcpsnoop प्रत्येक `Mcp-Param-{Name}` हेडर भी दिखाता है और, जब मिलान वाली विज्ञापित टूल परिभाषा ज्ञात होती है, तो उसकी तुलना एनोटेटेड तर्क पथ से करता है। नेस्टेड प्रॉपर्टीज़, Base64 सेंटिनल, बूलियन और संख्यात्मक-समतुल्य सुरक्षित पूर्णांकों को बिना स्ट्रिंग-तुलना के गलत-सकारात्मक परिणामों के संभाला जाता है। अज्ञात पैरामीटर हेडर और बिना मिलान वाली टूल परिभाषा वाले सत्र अवलोकन-मात्र बने रहते हैं। कुंजी- और मान-आधारित रिडक्शन कैप्चर किए गए पैरामीटर-हेडर मानों पर उनके सिंक तक पहुँचने से पहले लागू होता है, और एक मान जिसे mcpsnoop ने स्वयं साफ़ किया है, उसे कभी असहमति के रूप में रिपोर्ट नहीं किया जाता।

### टूल परिभाषा विचलन का पता लगाएं

किसी सर्वर लेबल के लिए देखी गई पहली पूर्ण `tools/list` उसका विश्वसनीय आधार बन जाती है। बाद के सत्र उस आधार की तुलना फ़ील्ड-दर-फ़ील्ड करते हैं: विवरण, शीर्षक, इनपुट और आउटपुट स्कीमा, एनोटेशन और आइकन, साथ ही जोड़े या हटाए गए टूल। एनोटेशन सबसे महत्वपूर्ण हैं, क्योंकि `readOnlyHint` के साथ स्वीकृत एक टूल जो बाद में स्वयं को विनाशकारी घोषित करता है, वही धोखा है जिसके लिए यह जाँच मौजूद है, और स्पेक क्लाइंटों को एनोटेशन को अविश्वसनीय मानने का निर्देश देता है। शीर्षक और आइकन इसलिए ट्रैक किए जाते हैं क्योंकि उपयोगकर्ता उन्हीं को देखता है, और स्पेक एक टूल के `title` को `annotations.title` और उसके नाम से ऊपर रैंक करता है। सत्रों की तालिका और टूल सारांश MCP ट्रैफ़िक को ब्लॉक या बदलने के बिना विचलन को चिह्नित करते हैं।

एनोटेशन की तुलना उनके स्पेक डिफ़ॉल्ट के माध्यम से की जाती है, इसलिए एक सर्वर जो एक ऐसे संकेत को स्पष्ट रूप से लिखना शुरू कर देता है जिस पर वह पहले से निर्भर था, रिपोर्ट नहीं किया जाता। mcpsnoop द्वारा किसी फ़ील्ड को ट्रैक करने से पहले दर्ज किया गया आधार उन फ़ील्डों के लिए काम करता रहता है जिन्हें वह दर्ज करता है, और बताता है कि किन फ़ील्डों के बारे में वह उत्तर नहीं दे सकता; जब आपको वर्तमान परिभाषाओं पर भरोसा हो, तो `mcpsnoop baseline --accept` से दोबारा रिकॉर्ड करें।

रिडक्शन जो रिकॉर्ड करता है, उसे बदलने से विचलन की तुलना भी बदल जाती है। `--redact-value` के बिना लिया गया और फिर उसके साथ लिए गए कैप्चर के विरुद्ध जाँचा गया आधार, साफ किए गए फ़ील्डों को बदले हुए रिपोर्ट करता है, जो सही है, क्योंकि दर्ज की गई परिभाषा वास्तव में बदल गई थी। रिडक्शन सेटिंग्स बदलने के बाद `--accept` के साथ दोबारा रिकॉर्ड करें।

प्रत्येक सर्वर के लिए एक स्थिर, अद्वितीय `--label` उपयोग करें जिसका कमांड नाम या लक्ष्य होस्ट अन्यथा टकराएगा। आधार सामान्य mcpsnoop स्टेट निर्देशिका के अंतर्गत संग्रहीत होते हैं, इसलिए `MCPSNOOP_HOME` और `XDG_STATE_HOME` लागू होते हैं।```bash
mcpsnoop check --fail-on drift session.jsonl
mcpsnoop baseline session.jsonl
mcpsnoop baseline --accept session.jsonl  # trust a legitimate definition change
mcpsnoop baseline --reset session.jsonl   # trust the next complete tools/list

`drift` `check` के लिए ऑप्ट-इन है; डिफ़ॉल्ट `error,invalid,warn` गेट अपरिवर्तित है।

### अप्रचलित प्रोटोकॉल सुविधाओं को फ़्लैग करें

2026-07-28 संशोधन Roots, Sampling और Logging को अप्रचलित करता है। वे कम से कम एक वर्ष तक काम करते रहते हैं, इसलिए mcpsnoop उन्हें त्रुटियों के रूप में मानने के बजाय चिह्नित करता है। स्ट्रीम, क्षमता निरीक्षक, और एक्सपोर्ट सभी उन्हें फ़्लैग करते हैं, और प्रत्येक मार्कर प्रतिस्थापन का नाम बताता है।

तीनों में से दो अब केवल मल्टी राउंड-ट्रिप अनुरोध के माध्यम से पहुंच योग्य हैं, जहां विधि का नाम फ्रेम पर ही न होकर सर्वर के `inputRequests` मैप के अंदर होता है। उन्हें भी फ़्लैग किया जाता है, ताकि जो सर्वर नए पैटर्न पर स्थानांतरित हो गया है वह चुपचाप रिपोर्ट करना बंद न कर दे।```bash
mcpsnoop check --fail-on deprecated session.jsonl

कॉलम चेतावनी रंग धारण करता है और कभी भी ERR कॉलम का लाल रंग नहीं, और mcpsnoop अभी भी अपने अग्रेषित ट्रैफ़िक के बारे में कुछ भी नहीं बदलता है।

कुछ भी हल या प्राप्त नहीं किया जाता। एक बाहरी `$ref` को केवल उसके रूप से पहचाना जाता है, और जिस स्कीमा की ओर वह इंगित करता है उसे कभी नहीं पढ़ा जाता।

### देखें कि सर्वर आपको संदर्भ में कितना खर्च करता है

टूल परिभाषाएँ हर वार्तालाप पर मॉडल के संदर्भ में प्रवेश करती हैं, और टूल परिणाम हर कॉल पर। टूल सारांश (`s`) आपके वास्तव में कैप्चर किए गए सत्र से दोनों को मापता है।

`definitions` पंक्ति निश्चित लागत है: एक भी कॉल किए जाने से पहले इस सर्वर का `tools/list` कितना वज़न रखता है। `DEF` कॉलम इसे प्रति टूल तोड़ता है, और `RESULT` वह है जो अब तक प्रत्येक टूल के उत्तरों की लागत रही है। तालिका त्रुटियों और विलंबता द्वारा क्रमबद्ध रहती है, इसलिए महंगी परिभाषाओं को खोजने के लिए `DEF` स्कैन करें; निर्यात उन्हें सबसे भारी पहले सूचीबद्ध करता है। तालिका के नीचे एक पंक्ति सबसे भारी एकल परिणाम का नाम बताती है, जिसे कुल योग छिपा देता है।

परिभाषा आंकड़े वे JSON हैं जिनमें से महत्वहीन रिक्त स्थान हटा दिया गया है, इसलिए जो सर्वर अपने `tools/list` को pretty-print करता है उसे उस सर्वर से अधिक महंगा नहीं गिना जाता जो नहीं करता, और वही सर्वर विभिन्न कैप्चरों में समान मापता है। `RESULT` वे बाइट्स हैं जैसे वे आए: एक परिणाम एक बार का पेलोड है, न कि सामान्यीकृत करने लायक अनुबंध।```bash
mcpsnoop export -T json | jq '.summary.definitions'

सॉकेट रिमोट की स्टेट डायरेक्टरी के अंतर्गत रहता है, जिसे `MCPSNOOP_HOME` के रूप में हल किया जाता है,
अन्यथा `XDG_STATE_HOME/mcpsnoop`, अन्यथा `~/.local/state/mcpsnoop`। डिफ़ॉल्ट रूप से mcpsnoop
आपके `user@host` से Linux होम `/home/<user>` मान लेता है और जब भी वह उस अनुमान पर
वापस आता है, stderr पर एक अनुस्मारक प्रिंट करता है। यदि रिमोट कहीं और हल होता है,
तो उस एक गैर-डिफ़ॉल्ट भाग का नाम बताएं।```bash
# a non-Linux or custom home, macOS is /Users/<user> and root is /root
mcpsnoop remote --remote-home /Users/remote-user remote-user@remote-host

# an explicit MCPSNOOP_HOME on the remote
mcpsnoop remote --remote-mcpsnoop-home /srv/mcpsnoop remote-user@remote-host

# an explicit XDG_STATE_HOME on the remote
mcpsnoop remote --remote-xdg-state-home /var/lib/state remote-user@remote-host

इसके बजाय एक स्थानीय प्रति रखने के लिए, लॉग्स को अपनी sessions निर्देशिका में scp करें और
सामान्य रूप से TUI चलाएँ।```bash
# copy the remote logs into your local sessions directory
mkdir -p ~/.local/state/mcpsnoop/sessions
scp remote-user@remote-host:'~/.local/state/mcpsnoop/sessions/*.jsonl' \
  ~/.local/state/mcpsnoop/sessions/

# open the TUI, it backfills the copied sessions
mcpsnoop

For remote workflows, use SSH tunnelling or SSH file transfer so transport auth, encryption, host verification, key rotation, and audit policy stay in your existing SSH setup.

रिमोट वर्कफ़्लो के लिए, SSH टनलिंग या SSH फ़ाइल ट्रांसफ़र का उपयोग करें ताकि परिवहन प्रमाणीकरण, एन्क्रिप्शन, होस्ट सत्यापन, कुंजी रोटेशन, और ऑडिट नीति आपके मौजूदा SSH सेटअप में बनी रहे।

## Contributing

## योगदान

Issues and pull requests are welcome. See [CONTRIBUTING.md](https://github.com/kerlenton/mcpsnoop/blob/HEAD/CONTRIBUTING.md) for the details.

इश्यू और पुल रिक्वेस्ट का स्वागत है। विवरण के लिए [CONTRIBUTING.md](https://github.com/kerlenton/mcpsnoop/blob/HEAD/CONTRIBUTING.md) देखें।

## License

## लाइसेंस

[MIT](https://github.com/kerlenton/mcpsnoop/blob/HEAD/LICENSE)

[MIT](https://github.com/kerlenton/mcpsnoop/blob/HEAD/LICENSE)