[Feature Request] Add Request/Response log Panel for Better Debugging

[ramonduraes]

Summary

I would like to suggest adding a Request/Response Dump Panel in the MCP Inspector tool to improve the developer experience during tool testing and debugging.

Motivation

Currently, when testing a Tool through the MCP Inspector, we can see the final output result, but we do not have visibility over:

• The exact JSON body that was posted.
• The headers sent (such as Content-Type and Accept).
• The full response body, including potential errors.
• The HTTP status codes returned by the MCP server.

This lack of visibility makes it harder to debug issues like:

• Incorrect input JSON structures.
• Deserialization or binding problems.
• Contract schema mismatches.
• Unexpected server-side behavior.

Adding a Request/Response Dump would make it much easier to understand and debug what is happening internally, especially when working with complex Tool schemas or diagnosing integration issues.

Proposed Solution

• After the user submits a Tool call:

  • Capture and display the HTTP Request details:
    • URL
    • Headers
    • Request Body (JSON)
  • Capture and display the HTTP Response details:
    • Status Code
    • Headers
    • Response Body (JSON or error message)

• Add a "Debug Mode" flag (e.g., a simple toggle button) in the UI that, when enabled, shows a collapsible panel or a new tab with:

  • [Request] section
  • [Response] section

• When Debug Mode is disabled, keep the UI clean as it is today, focusing only on the final result.

Benefits

• Easier debugging of input/output issues.
• Faster detection of problems in request formatting.
• Immediate visibility of server responses, including errors.
• A smoother developer experience when building or testing MCP servers.
• Helpful for reporting precise bugs or behavior inconsistencies.

Possible Example

[Request] POST http://localhost:5000/message Headers: Content-Type: application/json Body: { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "example.tool", "arguments": { "param1": "value" } } }

[Response] Status: 200 OK Headers: Content-Type: application/json Body: { "jsonrpc": "2.0", "id": 1, "result": { "success": true } }

Final note

Thank you very much for the great work on MCP Inspector. Adding a Debug Mode with a Request/Response Dump panel would make the tool even more powerful and greatly enhance development and debugging workflows!

[olaservo]

Thanks for the suggestion - would adding this to the console logs basically solve the same problem, without needing to add another section to the UI?

[ramonduraes]

Thanks for the suggestion - would adding this to the console logs basically solve the same problem, without needing to add another section to the UI?

I understand that console logs help to some extent, but the real challenge when integrating with MCP goes far beyond raw logging.

In real-world development and debugging, we often face issues like:

• JSON payload mismatches
• Unexpected binding failures
• Difficulties in understanding input schemas
• Validation errors that are not visible in simple console dumps

The main point is not just logging, but enabling structured and clear inspection of the data, in a unified place that simplifies debugging.

A visual panel (even a collapsible one) would greatly improve the developer experience (DX), making testing faster, clearer, and reducing errors.

I fully understand the importance of keeping the interface simple, but I believe that considering an optional inspection mode could add even more value to the community.

Thank you again for considering this suggestion.

[gsbattochio]

I agree with you Ramon. Delivering a faster and more intuitive experience through the portal is highly valuable and significantly reduces the time developers spend troubleshooting issues. While logs remain important, they often demand considerable time to review in detail.

[hesreallyhim]

+1 i would like to be able to see the payloads and not just contents more easily. For me, adding them to the server logs would satisfy my current itch, and might be a quick win, but that's just me.

[olaservo]

Closing as not planned and labeling with v2 in case we want to review for next version.