Validate an MCP message
Start with one copied message. Identify its role, fix the core JSON-RPC or tool-definition shape, and write down what still needs an SDK test.
- 1Identify the message
- 2Read findings
- 3Inspect correction
- 4Compare the pair
Identify the source and message
The source does not change validation. It records where the fixture came from.
Read the structural findings
Errors block the core shape. Warnings identify a likely interoperability problem.
Inspect the corrected fixture
The correction fills only required core structure. It cannot infer server-specific arguments or permissions.
Compare a request and response
Paste the related message to check direction and matching IDs. Leave it empty when you only have one message.
- Paste a related message to compare the pair.
Ready
Use this workflow when…
- MCP Inspector shows a message but the failure is not obvious.
- An SDK test or debug log contains a tools/list or tools/call payload.
- You need to separate JSON-RPC envelope errors from runtime, transport, auth, or tool errors.
Identify the message before fixing it
A request, response, tools/list result, and single tool definition have different required fields.
A structurally valid message can still fail because of protocol-version differences, transport framing, authorization, server state, invalid arguments, or tool execution. Run the corrected message through the exact client and server versions you use.
Check these failure boundaries
The local validator deliberately stops before transport and execution.
Where the result can go
Download the result first. It stays useful without another product.