MCP Spotlight: Mockzilla — API Mocking That AI Agents Control

Server: Mockzilla by mockzilla Stars: 808 · License: MIT · Language: Go MCP Transport: stdio (via npx @mockzilla/mcp) Last updated: May 15, 2026

What It Does

Mockzilla turns any OpenAPI specification into a live, running mock server — and with its MCP integration, your AI agent can do it for you.

No configuration files. No local servers to manage manually. Your agent reads an OpenAPI spec, installs the Mockzilla CLI if needed, and spins up a fully functional mock API on a free port. When you're done testing, it stops the server. The entire workflow — from spec to running mock to teardown — happens through natural language instructions.

The engine underneath is battle-tested: Mockzilla has been validated against 2,200+ real-world OpenAPI specifications covering 98,000+ endpoints with zero failures. It generates realistic responses from your schema, validates incoming requests against the spec, and can even proxy real backends with automatic mock fallback — so you can mix real and mocked endpoints in the same server.

Why It Matters for AI Agent Development

API mocking has always been a friction point in development workflows. You need third-party sandboxes, local mock servers, or hand-crafted stubs. Each of these breaks down when an AI agent is driving the development process:

• Sandboxes require accounts and setup — your agent can't sign up for a Stripe test account mid-workflow
• Local mock servers need human operators — starting, stopping, and configuring them is manual work
• Hand-crafted stubs go stale — they drift from the actual API contract the moment the spec updates

Mockzilla's MCP server solves all three. The agent:

1. Fetches or receives an OpenAPI spec URL
2. Calls peek_openapi to understand the endpoints
3. Calls serve_locally to spin up the mock
4. Iterates on client code against the live mock
5. Calls stop_locally when done

All without leaving the editor. All driven by the same agent that's writing the integration code.

The Two-Plane Architecture

Mockzilla's MCP bridge exposes a two-plane design that's worth understanding:

Plane	Requires Token?	Capabilities
Local	No	Install CLI, serve mocks locally, peek at specs, mock single endpoints
Hosted	Yes (MOCKZILLA_TOKEN)	List sims, deploy hosted mocks, manage shared environments

Without a token, everything happens on the agent's machine — nothing leaves localhost. This is the default and recommended mode for agent-driven development. With a token, the agent can also manage team-shared simulations on mockzilla.org, including per-PR mock URLs that deploy automatically via GitHub Actions.

Connecting Mockzilla to Facio

Step 1: Register the MCP Server

{
  "action": "add",
  "name": "mockzilla",
  "config": {
    "command": "npx",
    "args": ["-y", "@mockzilla/mcp@latest"]
  }
}

Step 2: Enable

{
  "action": "enable",
  "name": "mockzilla"
}

Step 3: Let Your Agent Work

Once enabled, your Facio agent gains 12 tools for API mocking. Here's what a typical session looks like:

You: "I need to test my payment integration against the Stripe API. Set up a mock."

The agent will:

1. Call peek_openapi on the Stripe OpenAPI spec to discover available endpoints
2. Call install_cli if Mockzilla isn't already installed (downloads to ~/.cache/mockzilla-mcp/ — never touches system PATH)
3. Call serve_locally with the spec URL to start a mock server
4. Return the local URL where your mock is running

You: "Now simulate a 3-second delay on the /v1/charges endpoint so I can test my timeout handling."

The agent adjusts the mock configuration through Mockzilla's middleware — no code changes needed.

You: "Done testing. Stop the mock."

The agent calls stop_locally and frees the port.

Production-Ready Patterns

CI/CD Integration Testing

One of Mockzilla's strongest use cases is zero-dependency CI pipelines. Because mocks run locally as a single binary, there are no external services to provision:

# .github/workflows/integration-test.yml
steps:
  - name: Start Mockzilla with all service specs
    run: |
      npx -y @mockzilla/mcp@latest serve_locally \
        --specs ./specs/stripe.yaml,./specs/sendgrid.yaml,./specs/twilio.yaml
  - name: Run integration tests
    run: npm test
    env:
      STRIPE_BASE_URL: http://localhost:2200/stripe
      SENDGRID_BASE_URL: http://localhost:2200/sendgrid

Your agent can generate this configuration automatically when you describe your service dependencies.

Selective Override Pattern

Mockzilla supports overriding specific endpoints while keeping the rest of the spec auto-generated. This is powerful for testing edge cases:

{
  "overrides": {
    "/v1/charges": {
      "POST": {
        "status": 402,
        "body": {
          "error": {
            "type": "card_error",
            "message": "Your card was declined."
          }
        }
      }
    }
  }
}

Your agent can dynamically add, modify, and remove overrides during a testing session — simulating payment failures, rate limits, timeout scenarios, and API version mismatches without touching the spec.

Air-Gapped Environments

For enterprise deployments where internet access is restricted, Mockzilla supports embedding OpenAPI specs directly into a portable Go binary:

package main

import (
    "embed"
    "github.com/mockzilla/mockzilla/v2/pkg/server"
)

//go:embed specs/*.yaml
var specs embed.FS

func main() {
    server.ServeEmbedded(specs)
}

This produces a single static binary that serves all your API mocks — deployable anywhere, with no network dependencies. Combined with Facio's Docker-first deployment model, you get a fully self-contained testing environment.

The Audit Trail Angle

When your agent manages mock servers via Mockzilla's MCP tools, every action is logged:

• Tool invocation: serve_locally called with spec URL and parameters
• Server lifecycle: start time, port, PID, endpoints served
• Override history: which endpoints were modified and when
• Teardown: stop_locally invocation with timestamp

Facio captures all of this in its immutable audit trail. For teams operating under compliance frameworks — SOC 2, ISO 42001, EU AI Act — this means every mock server an agent created, modified, or destroyed during a testing session is fully traceable. You can reconstruct exactly which API contracts were tested, with which overrides, at what time.

Mockzilla vs. Other API Mocking Approaches

Tool	Agent-Native	Zero-Config	Multi-Service	OpenAPI-Validated	Air-Gapped
Mockzilla MCP	✓	✓	✓	✓ (2,200+ specs)	✓
Prism (Stoplight)	—	✓	—	—	—
WireMock	—	—	—	—	✓
Mockoon Cloud	—	—	—	—	—
Hand-crafted stubs	—	—	—	—	✓

Mockzilla is the only approach that's agent-native: designed from the ground up for AI tools to control the mock lifecycle. It's not a mock server with an API bolted on — it's a mock server with MCP as a first-class interface.

Key Takeaways

• Agent-driven mocking: Mockzilla lets AI agents install the CLI, serve mocks, and tear them down — no human in the loop needed for mock lifecycle management
• Zero-config local plane: No account, no token, no setup. The agent handles everything through MCP tools
• 2,200+ specs validated: The engine is tested against real-world OpenAPI specs, not toy examples
• CI/CD ready: Single binary, zero external dependencies. Works in GitHub Actions, GitLab CI, and air-gapped environments
• Facios Audit-Trail: Jede Agent-Aktion am Mock-Server wird protokolliert — vollständige Nachvollziehbarkeit für Compliance-Frameworks
• MIT licensed: Enterprise-safe, no vendor lock-in

---

Mockzilla: mockzilla.org · MCP Server: npm @mockzilla/mcp · GitHub: github.com/mockzilla/mockzilla · Facio MCP docs: facio.bot/docs/mcp