One of the most powerful uses of MockServer's MCP integration is AI-assisted HTTP debugging. By combining MockServer's traffic recording capabilities with an AI assistant's ability to analyse data and suggest fixes, you can quickly diagnose and resolve HTTP integration issues.

Overview

The debugging workflow follows four steps:

  1. Set up a forwarding proxy to capture traffic
  2. Send traffic through MockServer
  3. Retrieve recorded request-response pairs for analysis
  4. Diagnose mismatches when requests don't match expectations

Throughout this workflow, your AI assistant uses MockServer's MCP tools to interact with the server — you describe the problem in natural language and the assistant handles the API calls.

 

Step 1: Set Up a Forwarding Proxy

Ask your AI assistant to configure MockServer as a forwarding proxy. This records all traffic while passing requests through to the real destination.

Example prompt:

"Set up MockServer to proxy all requests to /api/* to api.example.com on port 443 over HTTPS"

The AI assistant will use the create_forward_expectation tool:

{
  "name": "create_forward_expectation",
  "arguments": {
    "path": "/api/.*",
    "host": "api.example.com",
    "port": 443,
    "scheme": "HTTPS"
  }
}

Now any request sent to http://localhost:1080/api/... will be forwarded to https://api.example.com/api/... and both the request and response will be recorded.

 

Step 2: Send Traffic Through MockServer

Configure your application or test to send requests through MockServer instead of directly to the destination. This typically means changing the base URL in your application configuration:

# Before (direct)
API_BASE_URL=https://api.example.com

# After (through MockServer)
API_BASE_URL=http://localhost:1080

Then run your application or test scenario as normal. MockServer will forward all requests and record the traffic.

 

Step 3: Retrieve Recorded Traffic

Ask your AI assistant to retrieve the recorded request-response pairs for analysis.

Example prompt:

"Show me all requests and responses to /api/payments"

The assistant will use the retrieve_request_responses tool to fetch the recorded data, then present it in a readable format with analysis of status codes, response times, headers, and body content.

 

Step 4: Diagnose Mismatches

When a request doesn't match an expectation you've configured, the debug_request_mismatch tool provides detailed information about why the match failed.

Example prompt:

"Why didn't my POST to /api/users match the mock I set up?"

The assistant will use the tool to compare your request against active expectations and report the specific fields that didn't match — such as a missing header, incorrect content type, or a path mismatch.

Example AI Prompts for Common Debugging Scenarios

Here are practical prompts you can use with your AI assistant for common debugging tasks:

"Why is my API call returning 500?"

The assistant will:

  1. Use retrieve_request_responses to find the failing request and its response
  2. Analyse the response body for error details
  3. Check whether the request matched a mock or was forwarded to a real server
  4. Suggest fixes based on the error details

"Show me all requests to /api/payments in the last 5 minutes"

The assistant will:

  1. Use retrieve_recorded_requests filtered by the path
  2. Present the requests in chronological order with method, headers, and body
  3. Highlight any unusual patterns (e.g., repeated requests, missing headers)

"Why didn't my request match the mock I set up?"

The assistant will:

  1. Read the mockserver://expectations resource to see active expectations
  2. Use debug_request_mismatch with the request details
  3. Report exactly which fields mismatched (e.g., "expected content-type application/json but received text/plain")
  4. Suggest corrections to either the expectation or the request

"Set up a proxy to capture traffic between my service and the payment API"

The assistant will:

  1. Use create_forward_expectation to set up forwarding
  2. Confirm the proxy is active
  3. Explain how to point your service at MockServer
  4. Offer to retrieve and analyse the captured traffic after you run your test

"Trace the full lifecycle of a specific request"

The assistant will:

  1. Use raw_retrieve with type LOGS to find recent log entries and identify the correlation ID for the request
  2. Use raw_retrieve with type LOGS and the correlationId parameter to get all log entries for that specific request
  3. Present the full lifecycle: request received → expectation matching attempts → match result → response returned
  4. Highlight which expectations were compared and why each didn't match

This is particularly useful for intermittent failures where you need to understand exactly what happened for a specific request.

Tips for Effective AI-Assisted Debugging

  • Be specific about paths and methods. Instead of "check my API calls", say "show me POST requests to /api/orders". This helps the assistant construct precise queries.
  • Start with reset. Before a debugging session, ask the assistant to reset MockServer so you have a clean slate without noise from previous tests.
  • Use forwarding proxies for live debugging. Rather than creating mock responses, set up forwarding to capture real traffic. This lets you see actual server responses.
  • Ask follow-up questions. After the assistant shows you recorded traffic, ask questions like "why does request #3 have a different response?" or "what's different about the headers on the failed request?"
  • Combine with verification. After fixing an issue, ask the assistant to set up a verify_request check so you can confirm the fix works: "Verify that POST /api/orders is called exactly once with a valid Authorization header."

Related Pages