Skip to main content
MCP tools often make HTTP requests to external APIs. The HTTP mocking system intercepts fetch() calls, enabling fully offline testing of your MCP server.

Why HTTP Mocking?

Consider a tool that fetches weather data:
Without HTTP mocking:
  • Tests fail offline
  • Tests depend on external API availability
  • Tests may hit rate limits
  • Tests are slow due to network latency
  • Tests can’t simulate error conditions

Basic Usage


URL Matching

Exact URL Match

Partial URL Match

URLs are matched if they contain the specified string:

Regular Expression

Custom Matcher Function


HTTP Methods

Convenience Methods

Full Mock Definition


Request Matching

Match by Headers

Match by Request Body


Response Helpers

httpResponse Utilities

Full Response Object


One-Time Mocks

Create mocks that only match a limited number of times:

Call Tracking

Track Mock Usage

Wait for Calls


Passthrough Mode

Allow unmatched requests to reach the real network:
By default, unmatched requests throw an error. Only enable passthrough when you specifically need some requests to hit real endpoints.

Verification

Assert All Mocks Used

Check Pending Mocks


Cleanup

Always call interceptor.restore() to restore the original fetch function. Failing to do so will affect other tests.

Pattern: Using try/finally

Pattern: beforeEach/afterEach

Global Disable


Real-World Examples

Testing OpenAPI Adapter

Testing Error Handling

Testing Rate Limiting


Best Practices

Do:
  • Always call restore() in cleanup
  • Use httpResponse helpers for common responses
  • Verify mocks were used with assertDone()
  • Mock at the appropriate level of detail
Don’t:
  • Forget cleanup (breaks other tests)
  • Enable passthrough without good reason
  • Over-mock (test real HTTP handling sometimes)
  • Hard-code response data that should be dynamic