Skip to main content
Glama

update_mock

Update an existing mock API endpoint. Replaces all fields including rules. IMPORTANT: When updating rules, you MUST provide the full updated rules array — partial updates are not supported. Use get_mock_detail first to read the current state before modifying. This also supports adding/removing stateful simulation fields (stateLookupExpr, stateCaptureExpr, stateCaptureVariables).

Input Schema

NameRequiredDescriptionDefault
nameYesDescriptive name of the mock endpoint
pathYesHTTP resource path, e.g. /v1/users/{id}
tagsNoTags for categorization and search
rulesNoFull replacement rules array for this mock. Rules are evaluated in ascending priority order. First match wins. Providing an empty array [] removes all rules and returns only the default response.
methodYesHTTP method (GET, POST, PUT, DELETE, PATCH, etc.)
mockIdYesDatabase ID of the mock endpoint to update
delayMsNoDefault latency delay in milliseconds
projectIdYesDatabase ID of the project
webhookUrlNoOptional outbound webhook URL to call after each request. LOCAL RELAY OPTION: If developing locally, instead of a public URL, you can use the 'simceptor://local/<path>' scheme (e.g. 'simceptor://local/api/payment/callback') to route webhook payloads through an active Local Relay WebSocket tunnel to your local server. ALWAYS call 'check_relay_status' first to verify if a relay session is active.
descriptionNoOptional description visible in the dashboard UI
soapEnabledNoSet to true to enable SOAP / WSDL mode for this mock. Auto-detected if responseHeaders contains 'xml' or responseBody starts with '<'.
wsdlContentNoOptional raw WSDL XML content definition for SOAP service discovery (?wsdl).
collectionIdNoOptional collection folder ID to move this mock to
responseBodyNoDefault response body (fallback when no rule matches). Supports dynamic expressions. IMPORTANT: For JSON responses, do NOT include raw newline characters (\n) in the JSON payload as it will make the JSON structure malformed. NOTE: the tool response includes a `responseBodyWarning` field if this doesn't look like valid JSON structurally.
webhookMethodNoHTTP method for the webhook. Default: POST.
collectionNameNoOptional collection folder name to assign or move this mock to
responseStatusNoDefault HTTP status code (fallback when no rule matches)
webhookDelayMsNoMilliseconds to wait before firing the webhook.
webhookHeadersNoJSON string of headers for the webhook request.
webhookPayloadNoWebhook request body. Supports dynamic expressions.
responseHeadersNoDefault response headers as JSON string
stateLookupExprNoExpression to load session state before evaluating rules. E.g. 'request.body.user_id'
stateCaptureExprNoExpression to determine the key for saving session state after this request. E.g. 'request.body.id'
stateCaptureVariablesNoJSON object mapping variable names to expressions for saving into state. E.g. '{"balance":"request.body.amount"}'. Values not starting with request./response./body./query./header./path./state./item./random./faker. are stored as literal strings as-is.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it flags full-replacement (destructive) semantics, that partial rule updates are unsupported, and that stateful simulation fields can be added/removed. It does not say what happens to omitted optional fields (cleared vs. preserved) or whether any permissions are required, leaving a real ambiguity for a 24-param mutation.

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?

Four sentences, front-loaded purpose, then the destructive-replacement warning in caps, then the prerequisite, then the stateful-field note. No filler or restatement of schema fields.

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

Completeness4/5

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

For a 24-parameter mutation with no annotations and no output schema, the description covers the two things an agent would otherwise get wrong: wiping data via partial rules and skipping the read-before-write step. Only the fate of omitted optional fields and any auth requirements are left unstated.

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 coverage is 100%, so the baseline is 3; the description earns an extra point by adding cross-parameter semantics the schema can't express — that the rules array is authoritative and must be complete, and that the three state* fields are the toggle points for stateful simulation.

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?

Starts with a specific verb+resource ('Update an existing mock API endpoint') and immediately adds the defining trait — full replacement including the rules array — which is what separates it from add_mock_rule/remove_mock_rule. An agent can tell which sibling to reach for without opening the schema.

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?

Names an explicit prerequisite ('Use get_mock_detail first to read the current state before modifying') and states the hard constraint for rule updates. It never explicitly contrasts with add_mock_rule/remove_mock_rule, but 'replaces all fields including rules' implies the distinction.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources