API Sandbox MCP

API testing has excellent GUI tools - and none of them are where developers increasingly work: inside an AI assistant. Copying URLs and tokens between a chat window and Postman breaks the flow that makes assistants productive in the first place.

API Sandbox MCP closes that gap. It is a Model Context Protocol server, published on npm, that exposes 42 tools covering the full API-testing lifecycle: environment management, HTTP requests, saved collections, OpenAPI spec exploration, mock data generation, multi-step flows, assertions, bulk test runs, and load testing. The assistant becomes the API client - "log in against staging, use the token to fetch my profile, and assert the response shape" is one sentence, not a tool-switching session.

The token problem, solved by a format

API responses are token-hungry - a single verbose JSON body can eat a conversation. The server answers with two mechanisms. TOON (Token-Oriented Object Notation), a compact YAML-inspired default output that eliminates JSON punctuation and saves roughly 40% of tokens per response. And verbosity levels on every request: minimal strips headers and truncates bodies (~95% savings), normal filters noise headers and caps body size (~75%), while the full untruncated response is always cached and retrievable by call_id - no re-sending required.

Designing tools for an LLM is a token-budget exercise: every response byte competes with the reasoning the model could be doing instead.

Variables flow through everything

Environments are named JSON variable sets stored in the user home directory. Every HTTP tool resolves {{variable}} placeholders against the active environment, and relative URLs resolve against BASE_URL - so a saved request written once runs against any environment. Groups bind environments to directory paths: enter a project folder, and its default environment activates automatically.

Flows: multi-step testing in one call

The flow_run tool executes an ordered sequence of requests where each step can extract values from its response body by dot-path and pass them forward as variables - the canonical login-then-use-the-token pattern:

{
  "steps": [
    {
      "name": "login",
      "method": "POST",
      "url": "{{BASE_URL}}/auth/login",
      "body": { "email": "test@example.com", "password": "..." },
      "extract": { "TOKEN": "token", "USER_ID": "user.id" }
    },
    {
      "name": "get_profile",
      "method": "GET",
      "url": "{{BASE_URL}}/users/{{USER_ID}}",
      "headers": { "Authorization": "Bearer {{TOKEN}}" }
    }
  ]
}

Variables accumulate across steps; a 5xx stops the flow while a 4xx lets it continue - matching how a human tester actually reacts to failures. Every step reports status, timing, and what it extracted.

Specs make the assistant an expert on your API

api_import pulls an OpenAPI 3.x spec from a URL or file and recursively resolves every $ref, allOf, oneOf, and anyOf at import time. From then on the assistant can list endpoints filtered by tag or method, drill into full parameter and schema detail, and generate correctly-typed mock request bodies - emails, UUIDs, timestamps, and enums respected. Import the Petstore spec and "add a pet with realistic data" becomes a two-tool conversation.

Everything round-trips: collections and environments export to portable project files and to Postman v2.1 format, and import back the same way. Your test suite is never trapped inside the tool.