Skip to main content
Glama
mockzilla

Mockzilla

Official
by mockzilla
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

setup_replay

Record a service's response once, then replay it for matching requests to stabilize API mocks. Configure recording scope, match fields, and upstream source, then restart to apply.

Instructions

Configure replay for a service: record a real response once, then serve it back for every matching request (VCR). Writes a replay: block into the service's config.yml.

ASK THE USER TWO THINGS BEFORE CALLING:

  1. Record from a real backend, or pin the mock's own output? With upstream_url the recording is the real backend's response. Without it, replay pins the generated response so repeat calls stop returning fresh random data, which is often what 'make it stable' means.

  2. One recording for the whole endpoint, or one per input? With no match fields the key is method and path only, so EVERY call to POST /foo replays the first response no matter what it sends. Look at what the endpoint actually takes, then ask which fields distinguish one case from another and pass those as match.

Match fields come from three sources: path (path variables, ignored unless listed), body (dotted paths like data.items[0].name, or "[0].name" for a top-level array, or flat keys for form bodies), and query. Returns recording_scope spelling out what each endpoint is keyed by. Only writes inside the bridge's own mocks dir; for a folder served from the user's project it returns the YAML and the path for them to apply. Config is read at startup, so restart after.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dirNoDirectory holding the service, when it is not one of the bridge's own mocks.
serviceYesService to record, as named in serve_locally's output.
durationNoHow long recordings live, e.g. "24h".
endpointsYesEndpoints to record.
auto_replayNoRecord and replay without the X-Mockzilla-Replay header.
upstream_urlNoReal backend to record from, e.g. "https://api.example.com". Omit to record the mock's own generated responses.
upstream_onlyNoRefuse to record anything that did not come from the upstream. Needs `upstream_url`, or every request answers 502.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.25

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden, and it delivers. It discloses the write side effect, the write scope ('only writes inside the bridge's own mocks dir'), the fallback behavior for user-served folders, and the requirement to restart because config is read at startup. This is exactly the kind of behavioral context agents need.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: core concept, mandatory user questions, matching syntax, write location, and restart requirement. It is front-loaded with the essential behavior and structured so an agent can extract the call-critical information quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description tells the agent what the tool returns ('recording_scope spelling out what each endpoint is keyed by'), what side effects occur, and what postconditions apply. For a multi-option setup tool, this is complete enough to call correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining operational semantics: match fields come from path, body, and query; body supports dotted paths; path variables are ignored unless listed; and omitting match keys on method+path alone. This meaningfully exceeds what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb and resource: 'Configure replay for a service' and immediately defines the behavior with a VCR analogy: 'record a real response once, then serve it back for every matching request.' It also states the concrete side effect, writing a `replay:` block into config.yml, which distinguishes it clearly from sibling tools like list_replays.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit pre-call guidance by telling the agent to ask the user two questions before calling, and explains the practical consequences of each choice. It doesn't name alternative tools or exclusions, but the decision context it provides is strong enough for an agent to know when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools