How do I use mcp-msgdump?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-msgdump analyze /tmp/mcp_session.jsonl --format summary" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-msgdump

by prasad-a-abhishek

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

mcp-msgdump

Zero-dependency MCP server and CLI that proxies, inspects, and analyzes JSON-RPC message streams between MCP clients and servers.

A passive MCP proxy that lets you see every JSON-RPC message crossing the wire — in CI, headless environments, or embedded in test suites.

MIT License Python 3.11+

Quick Start

# Install (PyPI package coming soon — use git install for now)
pip install git+https://github.com/prasad-a-abhishek/mcp-msgdump.git

# Analyze a trace log
mcp-msgdump analyze /tmp/mcp_session.jsonl --format summary

# Run as an MCP proxy (all messages forwarded + logged to stderr)
mcp-msgdump proxy --target localhost:3000 --port 8080

# Library API
from mcp_msgdump import analyze_log, check_schemas, replay_session

report = analyze_log("/tmp/mcp_session.jsonl")
print(report.total_requests)       # e.g. 47
print(report.error_count)          # e.g. 3
print(report.tools_called)          # ['read_file', 'write_file', 'list_dir']

Related MCP server: mitmproxy-mcp

Why mcp-msgdump?

MCP server developers debugging transport issues and AI tooling integrators validating MCP server behavior in CI have no way to inspect, replay, or audit the JSON-RPC message stream without manual debugging or complex proxy setups. Existing tools either require a browser GUI (MCP Inspector), are tied to a specific visualization layer (mcp-reticle), or are too lightweight to be useful in headless/CI environments.

mcp-msgdump is the only zero-dependency, stdio-native MCP server that provides both proxy inspection and structured log analysis, usable in both interactive CLI sessions and automated CI pipelines.

Key Features

Zero dependencies — pure Python 3.11+ stdlib only; no pip install surprises
Two operating modes — proxy (pass-through with logging) and analysis (structured report from a log file)
MCP stdio server — exposes analyze_log, replay_session, and check_schemas as MCP tools
Structured output — JSON output for machine consumption, summary format for humans
CI-friendly — non-zero exit codes on malformed input, headless/stdin-safe, no GUI required
Schema auditing — detects dangerously untyped parameters, missing descriptions, and empty object types

CLI Reference

mcp-msgdump [--help]
mcp-msgdump analyze [FILE] [--format {summary,json}]
mcp-msgdump proxy --target HOST:PORT [--port PORT]

`analyze` subcommand

Parses a JSONL log file and emits a structured analysis report.

Flag	Description
`FILE`	Path to JSONL log file (use `-` for stdin)
`--format summary`	Human-readable summary to stdout (default)
`--format json`	Machine-readable JSON to stdout

Exit codes: 0 clean log, 1 file not found or malformed input.

`proxy` subcommand

Runs as a passive man-in-the-middle between an MCP client and server. All traffic is forwarded verbatim; every message is also emitted to stderr.

Flag	Description
`--target HOST:PORT`	Target MCP server address (required)
`--port PORT`	Listen port for the proxy (default: 8080)

Library API Reference

`analyze_log(path: str) -> AnalysisReport`

Parse a JSONL log file and return an AnalysisReport:

from mcp_msgdump import analyze_log

report = analyze_log("/tmp/session.jsonl")
assert report.total_requests == 47
assert report.error_count == 3
assert "read_file" in report.tools_called
assert report.schema_issues == []

`check_schemas(path: str) -> list[SchemaIssue]`

Validate tool schemas in a log file. Returns a list of issues:

from mcp_msgdump import check_schemas

issues = check_schemas("/tmp/session.jsonl")
for issue in issues:
    print(f"[{issue.severity.value}] {issue.tool_name}.{issue.parameter_name}: {issue.message}")

Issues detected:

type: string with no description → dangerously_untyped warning
type: object with no properties → empty_object warning
Missing type annotation → missing_type error
Missing description on typed parameter → missing_description warning

`replay_session(path: str, start_index: int = 0, filter_tool: str | None = None) -> list[ReplayResult]`

Replay tool calls from a log file, optionally filtered:

from mcp_msgdump import replay_session

results = replay_session("/tmp/session.jsonl", filter_tool="read_file")
for r in results:
    print(f"#{r.index} {r.tool_name}: {r.params}")

Data Models

from mcp_msgdump import AnalysisReport, ReplayResult, SchemaIssue, ToolCall, Mismatch, Severity

# AnalysisReport fields:
report.total_requests    # int — count of JSON-RPC requests seen
report.error_count       # int — count of error responses
report.tools_called      # list[str] — unique tool names called
report.slowest_call     # ToolCall | None — slowest tool call by latency_ms
report.schema_mismatches # list[Mismatch] — schema mismatches (v1: always empty)
report.tool_calls        # list[ToolCall] — all tool call records
report.schema_issues     # list[SchemaIssue] — detected schema issues
report.batch_sub_requests # int — count of sub-requests inside batch arrays
report.empty_file       # bool — true if input was empty
report.malformed_lines   # int — count of unparseable lines

# ToolCall fields:
tc.method               # str — JSON-RPC method name (e.g. "tools/call")
tc.params              # dict — parameters passed to the tool
tc.id                  # int | str | None — request ID
tc.latency_ms          # float | None — latency in ms (set when response has duration)
tc.is_notification     # bool — true if id was null (no response expected)
tc.is_error            # bool — true if response contained an error
tc.error_message       # str | None — error message if is_error is True

# ReplayResult fields:
r.index                # int — position in the log
r.method               # str — JSON-RPC method name
r.params               # dict — parameters
r.response             # dict | None — response if available
r.skipped              # bool — true if filtered out by filter_tool
r.skip_reason          # str | None — reason if skipped

# SchemaIssue fields:
issue.tool_name        # str — name of the tool
issue.parameter_name   # str | None — affected parameter name
issue.issue_type       # str — e.g. "untyped", "dangerously_typed", "missing_description"
issue.message          # str — human-readable description
issue.severity         # Severity — Severity.WARNING or Severity.ERROR

# Mismatch fields:
m.tool_name            # str
m.field                # str
m.expected              # Any
m.actual               # Any
m.description          # str | None

Limitations

The proxy mode is a TCP socket proxy — it does not speak the MCP stdio protocol over the proxy itself (the proxy is for TCP-based MCP servers)
MCP stdio server mode only; HTTP/SSE transport is out of scope for v1
Streaming/chunked JSON-RPC is not supported in v1
No persistent storage — logs are written to a file or stdout, not internally buffered
No authentication, access control, or rate limiting

Non-Goals

Executing tools or making real network calls beyond forwarding to the proxy target
Visualization or GUI output
HTTP/SSE MCP server transport
Persistent internal log storage
Authentication or rate limiting

Test Suite

pytest -v

165 tests covering: proxy forwarding, log analysis, schema checking, replay, CLI parsing, MCP protocol, and zero-dependency enforcement.

MCP Client Configuration

mcp-msgdump is a stdio MCP server — point any MCP client at it to capture and analyze JSON-RPC traffic.

Claude Desktop (claude_desktop_config.json)

{
  "mcpServers": {
    "mcp-msgdump": {
      "command": "python",
      "args": ["-m", "mcp_msgdump", "analyze", "/path/to/session.jsonl"]
    }
  }
}

Cursor

Add to Cursor settings (JSON mode):

{
  "mcpServers": {
    "mcp-msgdump": {
      "command": "python",
      "args": ["-m", "mcp_msgdump", "analyze", "/path/to/session.jsonl"]
    }
  }
}

Windsurf

Add to Windsurf MCP settings:

{
  "mcpServers": {
    "mcp-msgdump": {
      "command": "python",
      "args": ["-m", "mcp_msgdump", "analyze", "/path/to/session.jsonl"]
    }
  }
}

Cline

Add to Cline MCP settings:

{
  "mcpServers": {
    "mcp-msgdump": {
      "command": "python",
      "args": ["-m", "mcp_msgdump", "analyze", "/path/to/session.jsonl"]
    }
  }
}

AGY

mcp_servers:
  mcp-msgdump:
    command: python
    args: ["-m", "mcp_msgdump", "analyze", "/path/to/session.jsonl"]

License

MIT — Prasad A Abhishek

Available Tools

3 tools

analyze_logA

Analyze a JSONL log file of MCP JSON-RPC messages and produce a structured report.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the JSONL log file to analyze.

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description must carry the behavioral transparency burden. It states the action (analyze) and output (structured report), implicitly suggesting it is read-only, but it does not explicitly mention side effects, file modification, authentication requirements, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and to the point, using two straightforward sentences. There is no redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description mentions a 'structured report' but does not specify the report's format, content, or any error behavior. Given the lack of an output schema, this omission leaves some ambiguity for an agent trying to anticipate the tool's result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, path, has a clear description stating it points to the JSONL log file to analyze. This adds meaningful context beyond the parameter name and type, even though the schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: analyzing a JSONL log file of MCP JSON-RPC messages and producing a structured report. It distinguishes this from sibling tools like replay_session and check_schemas by specifying the input format and action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given about when to use this tool versus the sibling tools. The description implies it is for analyzing logs, but it does not state conditions or alternatives, leaving the agent to infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_schemasB

Check tool schemas in a log file for common issues such as missing descriptions or untyped parameters.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the JSONL log file to check.

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose side effects, permissions required, read-only status, or output format. It only says it 'checks' schemas, which is minimal behavioral information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no unnecessary words or repetition. It clearly conveys the tool's core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the main purpose. However, it does not explicitly state what the tool returns or whether it produces a report, which would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'path' is fully described in the schema, and the description reinforces that it is a log file path. Since schema coverage is 100%, the baseline of 3 applies; the description does not add extra semantic detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's specific action ('Check tool schemas in a log file') and its purpose ('for common issues such as missing descriptions or untyped parameters'). It is distinguishable from sibling tools like analyze_log and replay_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use this tool versus the sibling tools. It does not mention alternatives or conditions for selection, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

replay_sessionA

Replay a log file of MCP messages, optionally filtered by tool name.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path to the JSONL log file to replay.
`filter_tool`	No	Only replay messages whose method contains this string.
`start_index`	No	Zero-based index to start replaying from. Default 0.

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of disclosing side effects. 'Replay' strongly implies that MCP messages will be executed or sent, which could cause side effects, but the description does not state this or any safety implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no redundant or vague wording. It efficiently communicates the core purpose and the optional filtering capability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic purpose and parameters, but it omits important context such as what happens when messages are replayed, whether the operation is safe, and what output or result is expected. Given no annotations or output schema, these gaps leave the description only partially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter has a corresponding description. However, the descriptions add little beyond the schema itself—for example, 'filter_tool' is described only as a string filter and 'start_index' as a zero-based index, with no additional semantics or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Replay a log file of MCP messages') and the optional filtering constraint ('filtered by tool name'). This distinguishes it from the sibling tool 'analyze_log', which implies analysis rather than replay.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool—when replaying a log—but does not explicitly state when to prefer it over alternatives like 'analyze_log' or when not to use it. The usage guidance is implicit rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0Sep 8, 2026
- First observedanalyze_log
- First observedcheck_schemas
- First observedreplay_session

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored 2026-09-08 08:55 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: analyze_log produces a report, replay_session replays a session, and check_schemas validates schemas. There is no meaningful overlap between the three.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: analyze_log, replay_session, check_schemas. The naming is predictable and easy to infer.

Tool Count5/5

Three tools is well-scoped for the apparent domain of MCP log inspection. Each tool has a distinct role without unnecessary bloat.

Completeness4/5

The core workflows of analyzing, replaying, and schema-checking are covered. Missing features like exporting results or filtering by time could exist, but the current set is reasonably complete for log analysis.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
JxBrowser MCP Server A
io.github.TeamDev-IP
MCP server to assist with JxBrowser development.
Developer Tools Browser Automation
22
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168
runtime
com.formatho
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Developer Tools Blockchain Security
1

Related MCP Servers

mcp-remote-py
Developer Tools
elphinsnow
F
license
Not graded
quality
D
maintenance
A minimal Python-based proxy that bridges local MCP STDIO clients with remote MCP SSE servers. It enables bidirectional JSON-RPC message passing between standard command-line tools and web-based remote endpoints.
Updated 7 months ago (2026-02-24 03:53 UTC)
1
-
mitmproxy-mcp
Browser Automation API Testing Penetration Testing
moha-abdi
A
license
Not graded
quality
D
maintenance
MCP server for mitmproxy that lets any MCP client analyze, intercept, and replay HTTP/HTTPS traffic.
Updated 7 months ago (2026-02-21 16:35 UTC)
9
MIT
MCPlexer
Developer Tools
OzTamir
A
license
Not graded
quality
B
maintenance
A tiny MCP proxy for running multiple labeled instances of the same MCP server without tool-name collisions.
Updated 3 months ago (2026-06-23 13:22 UTC)
6
1
MIT
debug-mcp-server
Developer Tools Testing & QA Tools
silentwasd
F
license
Not graded
quality
C
maintenance
A minimal MCP server for debugging MCP clients. It echoes back everything it receives — tool arguments, session IDs, metadata — so you can inspect exactly what your client is sending.
Updated 3 months ago (2026-06-23 11:49 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/prasad-a-abhishek/mcp-msgdump'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-msgdump

Quick Start

Why mcp-msgdump?

Key Features

CLI Reference

analyze subcommand

proxy subcommand

Library API Reference

analyze_log(path: str) -> AnalysisReport

check_schemas(path: str) -> list[SchemaIssue]

replay_session(path: str, start_index: int = 0, filter_tool: str | None = None) -> list[ReplayResult]

Data Models

Limitations

Non-Goals

Test Suite

MCP Client Configuration

Claude Desktop (claude_desktop_config.json)

Cursor

Windsurf

Cline

AGY

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`analyze` subcommand

`proxy` subcommand

`analyze_log(path: str) -> AnalysisReport`

`check_schemas(path: str) -> list[SchemaIssue]`

`replay_session(path: str, start_index: int = 0, filter_tool: str | None = None) -> list[ReplayResult]`