Skip to main content
Glama

Add a mock rule

proxy_mock_response

Mock HTTP responses by adding rules matched on method and URL, supplying response body inline or from a file, and optionally simulating network delays or bandwidth limits.

Instructions

Add an in-memory mock rule. Matches on HTTP method + URL pattern (glob/substring by default against the full URL; set regex=true for a raw regex). Body is supplied inline or via a fixture file on disk. Provide either 'body' or 'bodyFile', not both. Optionally simulate a slow server: delayMs waits before responding (processing time), bandwidthKbps streams the body at a KB/s rate (slow network / big object from far away).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL pattern. Default is glob/substring matched against the full absolute URL (e.g. 'api.example.com/v1/user' or '*/v1/user'). With regex=true, a raw JS regex source.
bodyNoInline response body (small payloads).
regexNoTreat 'url' as a raw regex (default false).
methodYesHTTP method: GET, POST, PUT, DELETE, PATCH, HEAD, or OPTIONS.
statusNoResponse status code (default 200).
delayMsNoSimulated server processing time: delay in milliseconds before the response starts (e.g. 3000 = 3s before the first byte).
headersNoResponse headers, e.g. { "content-type": "application/json" }.
bodyFileNoPath to a fixture file whose contents become the response body (large payloads). Must be inside the proxy's allowed directories (default: the folder the proxy was launched from). Add --allowed-dir <path> at launch to permit others.
bandwidthKbpsNoSimulated network bandwidth cap: stream the body at this many KB/s (e.g. 50 = slow-network feel, big objects arrive progressively).
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 does an excellent job. It discloses key behaviors: default glob/substring matching against full URL, regex option, mutual exclusivity of body/bodyFile, delayMs processing time, bandwidthKbps streaming, and bodyFile directory restrictions. This goes well beyond a basic description and gives the agent critical operational context.

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 two sentences, front-loaded with the core purpose, and every clause earns its place. It efficiently packs matching logic, body options, and simulation parameters without redundancy or fluff.

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 9 parameters, complex interactions (body/bodyFile exclusivity, regex vs glob, delay/bandwidth), and no output schema, the description provides enough context for an agent to use it correctly. It covers the main behavioral aspects and edge constraints, making it a complete standalone reference.

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. However, the description adds meaningful cross-parameter guidance (e.g., 'Provide either body or bodyFile, not both'), clarifies the matching default and regex flag, and explains the semantics of delayMs and bandwidthKbps in a way not fully captured by each parameter's individual description.

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

Purpose4/5

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

The description clearly states the verb 'Add' and the resource 'in-memory mock rule', and specifies matching on HTTP method + URL pattern. It distinguishes from proxy_stop/health/list tools, though it does not explicitly differentiate from the transform-based mock tools (e.g., proxy_mock_transform), so sibling differentiation is not fully explicit.

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

Usage Guidelines3/5

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

The description explains how the tool works (matching, body options, slow-server simulation) but does not provide explicit guidance on when to use this tool versus alternatives like proxy_mock_transform or proxy_request_transform. Usage is implied through the functional details, but no when-not or alternative suggestions are given.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shahfazliz/proxy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server