MCPtrove interactive resource
MCP JSON-RPC Log Analyzer — Summarize Methods, Errors, and IDs
Turn pasted JSON-RPC traffic into a compact, issue-ready summary without uploading logs.
The reusable resource
A local JSON-RPC traffic summary for methods, error codes, successes, and unmatched request IDs.
MCP JSON-RPC Log Analyzer turns newline-delimited JSON-RPC traffic into a local method, error, and request-ID summary that is easier to cite in a bug report.
Contents
- What the tool does
- How to use it
- How the analysis works
- How to interpret the output
- Limitations and privacy
- Practical next steps
- Related MCPtrove resources
- FAQ
What the tool does
The MCP JSON-RPC Log Analyzer turns raw protocol output into a compact incident summary. Paste a JSON object, JSON array, or newline-delimited JSON objects into the page, and the analyzer examines the content directly in your browser.
The summary helps answer common review questions:
- Which methods appear in the log?
- How many requests or notifications are present?
- Which responses contain results?
- Which responses contain errors?
- Do response IDs match earlier request IDs?
- Which request IDs have no response?
- Which response IDs have no matching request?
- Are any JSON values valid but not recognizable as JSON-RPC-shaped messages?
The tool is designed for diagnosis and communication. Method counts, error entries, and request-ID checks make mixed traffic easier to explain in an issue or handoff.
You can also copy or download a Markdown summary. That provides a practical path from a large pasted log to a concise record of the methods involved, failures observed, and identifiers requiring review.
How to use it
Begin with the smallest excerpt that still shows the behavior under investigation. A focused sample is easier to interpret and reduces the chance of exposing unrelated parameters, credentials, or personal information.
The analyzer accepts:
- A single JSON object.
- A JSON array.
- Newline-delimited JSON objects, with one object per line.
For newline-delimited input, each line must be readable JSON. If parsing fails, the tool identifies the first unreadable line so you can correct it, remove it, or narrow the excerpt before trying again.
Use this workflow:
| Step | Action | Review purpose |
|---|---|---|
| 1 | Copy a focused log excerpt | Keeps the evidence understandable |
| 2 | Redact secrets before pasting | Limits exposure of sensitive values |
| 3 | Paste one supported JSON format | The analyzer detects the shape |
| 4 | Review methods and message categories | Shows what traffic is present |
| 5 | Compare errors with request IDs | Separates reported failures from incomplete capture |
| 6 | Copy or download the Markdown summary | Creates a shareable issue or handoff record |
Review the method table, error table, and request-ID audit together. A sample with requests but no responses may represent a stopped connection, an excerpt that ends early, or a capture that omitted part of the exchange.
Parsing occurs in the browser, and the input is not uploaded as part of the analysis flow described here. You remain responsible for reviewing the content before pasting, copying, downloading, or sharing it.
How the analysis works
The analyzer recognizes JSON-RPC-shaped messages when they contain a method, result, error, or id field. It groups recognized content into practical categories and reports other JSON values as unclassified.
Messages with methods are counted as requests or notifications. Messages with results are counted as successful responses. Messages with errors are counted as error responses. The method table counts each method string found in the pasted content, including repeated occurrences.
The error table groups numeric or string error codes with their associated messages. It describes the failures present in the excerpt; it does not determine their root cause.
The request-ID audit compares IDs found on requests with IDs found on responses. It can identify request IDs with no response and response IDs with no matching request. Matching IDs support a correspondence within the pasted sample, but they do not prove that the entire transport exchange was correct.
The analyzer preserves the pasted sequence for review. It does not infer timing beyond that sequence, and it does not calculate latency. Generic JSON-RPC messages do not provide a standard timestamp field, so timing analysis requires the original logging system or another time-aware tool.
How to interpret the output
Start with the method table. It shows which operations occur in the excerpt and whether the sample is concentrated around one operation or spread across several. Frequency is context, not a severity rating.
Next, review the message categories. A large number of requests without responses may indicate an incomplete excerpt, omitted traffic, or a connection that stopped responding. The analyzer can show the pattern but cannot establish its cause from the log alone.
Use the error table to identify repeated codes or messages. In a bug report, pair those entries with the relevant methods so readers can see both the attempted operation and the reported failure.
Then examine the ID audit:
- A request ID without a response may mean the excerpt ends before the response, messages were filtered, or the request was not answered in the captured traffic.
- A response ID without a matching request may mean the excerpt begins late, traffic was merged from different sources, or content was duplicated or reordered.
- Duplicate IDs require manual review because the analyzer cannot determine whether they reflect retries, merged captures, or logging artifacts.
Unmatched IDs are review signals, not proof of a server defect, protocol violation, or security problem. If unclassified JSON values appear, inspect them manually. They may be valid JSON that represents configuration, wrapper output, or another structure mixed into the log.
Limitations and privacy
The analyzer is a log review aid, not a complete protocol monitor. Partial logs naturally produce unmatched IDs. A copied beginning or ending fragment may omit the corresponding request or response even when the full session was valid.
Batched traffic also needs human review. An array can contain several JSON values, and the surrounding context may matter when deciding whether those values belong to one exchange or multiple exchanges. Use the summary to focus attention, then inspect the original content where necessary.
The tool does not calculate latency or reconstruct a complete session. If timing matters, preserve timestamps from the original logging system and analyze them separately. Do not infer duration from line order.
Redact sensitive values before analysis. Tokens, passwords, private URLs, API keys, personal data, and other secrets may remain in params or error details. The MCP Config Redactor can help prepare content for safer sharing, but verify the redacted result manually before attaching it to an issue.
A browser-based workflow reduces the need to upload the log for this analysis, but it does not make pasted content automatically safe. Review both the original excerpt and the generated Markdown summary before sending them elsewhere.
Practical next steps
Use the analyzer when you already have JSON-RPC-shaped traffic and need a structured account of its methods, responses, errors, and IDs.
Choose the next step based on the evidence:
- For possible configuration problems, use the MCP Config Validator.
- For symptom-specific repair guidance, review MCPtrove troubleshooting.
- Before sharing logs or configuration, use the MCP Config Redactor.
- If the excerpt is incomplete, capture a focused sample containing the relevant request and surrounding response or error.
Keep the original sample separately from the redacted version. In the report, state that the analyzer summarizes the pasted excerpt and note whether it was partial, batched, reordered, or affected by duplicate IDs.
Related MCPtrove resources
The MCP Config Redactor helps prepare configuration and log content for safer sharing.
The MCP Config Validator helps check whether malformed configuration contributes to a startup or connection problem.
The troubleshooting guides provide symptom-specific repair paths when the summary points to a broader setup or runtime issue.
FAQ
Does the analyzer upload my log?
Parsing occurs in the browser, and the tool accepts content directly in the page. Redact secrets before pasting or sharing because sensitive values inside parameters are not automatically removed.
Can it calculate request latency?
No. Generic JSON-RPC messages do not include a standard timestamp field, so the analyzer does not calculate latency. Use timestamps from the original logging system for timing analysis.
What does an unmatched request ID mean?
It means the pasted sample contains a request ID without a corresponding response ID. The log may be partial, filtered, reordered, or incomplete. Treat the result as a review signal rather than proof that the request permanently failed.
Why are some JSON values unclassified?
The analyzer recognizes messages through method, result, error, or id fields. Valid JSON that does not match those shapes is reported as unclassified and may require manual inspection.
Can I use the summary in a bug report?
Yes. Copy or download the Markdown summary, review it for sensitive content, and add context about whether the log was complete or partial. Mention any duplicate IDs, batched messages, or unclassified values that still need review.