Skip to main content
Glama

mock_endpoint

Mock a single HTTP endpoint without writing an OpenAPI spec. Provide the method, exact path, and response body to start a local mock server and return the requested response.

Instructions

Quickly mock a single HTTP endpoint without writing an OpenAPI spec. Pass method (default GET), path (the EXACT HTTP path the user described, including all segments), and the response body (object → JSON, string → text). The bridge writes the response into a managed static dir at ~/.cache/mockzilla-mcp/mocks/ and (re)starts a single shared mockzilla server pointing at it.

Pass path AS IS. Do NOT prepend or duplicate any segment. The bridge derives the service name from the first segment for internal grouping, but it does not change the URL the user hits. Examples: • User says GET /pets/{id} → call mock_endpoint with path=/pets/{id} → URL is http://HOST:PORT/pets/{id} • User says POST /orders → path=/orders → URL is http://HOST:PORT/orders • User says GET /v1/users/me → path=/v1/users/me → URL is http://HOST:PORT/v1/users/me

Pass status and/or headers to mock a failure or a redirect with a real body: status: 404 with an error payload, 201 with a Location, 429 with Retry-After. Omit response to send no body at all, which 204 and 304 require. These need mockzilla 2.8.20 or newer; the tool says so if the installed CLI is older. To fail a share of requests instead of every one, use serve_locally with errors.

Path placeholders like {id} are stored as literal directory names — by default ALL placeholder values share the same response. To return different responses for specific values, call mock_endpoint again with a literal value (e.g. /pets/123).

Calling this multiple times accumulates endpoints in the same server — adding POST /pets after GET /pets/{id} keeps both. Mutually exclusive with serve_locally: stop any ad-hoc server first. See mockzilla_docs_search('static directory') for the underlying convention.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath beginning with /. First segment is the service name.
methodNoGET
statusNoResponse status. Omit `response` alongside it for a body-less response, which is what 204 and 304 need.
headersNoExtra response headers, e.g. {"Location": "/orders/42"}. A Content-Type here wins over `content_type`.
responseNoResponse body. Object → JSON. String → text. Default {}.
content_typeNoOverride content type. Inferred from response type if omitted (object → application/json, string → text/plain).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.22
    • addedInput schema / properties / headers
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "description": "Extra response headers, e.g. {\"Location\": \"/orders/42\"}. A Content-Type here wins over `content_type`.",
      +  "type": "object"
      +}
    • addedInput schema / properties / status / description
      Added value: +"Response status. Omit `response` alongside it for a body-less response, which is what 204 and 304 need."
    • changedInput schema / properties / status / minimum
      Previous value: -100New value: +200
  2. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does so thoroughly. It discloses the write location ~/.cache/mockzilla-mcp/mocks/, server (re)start behavior, endpoint accumulation across calls, literal storage of placeholders, version requirements, and side effects of repeated calls. This is exemplary behavioral disclosure.

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 tightly organized: primary use case first, then path rules with examples, then status/header behaviors, then accumulation and conflict rules. Each sentence earns its place by adding operational detail rather than padding.

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?

For a tool with no output schema and no annotations, the description covers selection, invocation semantics, side effects, version caveats, and interactions with related tools. An agent has everything needed to call it correctly and predict the result.

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

Parameters5/5

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

Even with 83% schema coverage, the description adds substantial value: path must be passed exactly as-is with explicit examples, response body conversion depends on type, status/headers enable failure and redirect responses, and omitting response is required for 204/304. These details go well beyond the schema property descriptions.

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 opening line states exactly what the tool does: 'Quickly mock a single HTTP endpoint without writing an OpenAPI spec.' This clearly distinguishes it from sibling tools like deploy_mock_from_spec and serve_locally. The examples reinforce the precise scope with concrete call patterns.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: quick single endpoint mocking without a spec. It also names an alternative for a different need—'use serve_locally with errors' for partial failures—and states the mutual exclusivity with serve_locally. This is strong routing that an agent can act on immediately.

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