Skip to main content
Glama

Fixter

by dev.fixter.mcp
OverviewDiscussionsAdmin

update_api_test

Replace the entire configuration of an existing API test (identified by apiTestId) with the supplied values — a full overwrite, not a partial patch, so pass every field you want to keep. Same parameters and request variables as create_api_test. Returns the updated API test and its state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesHuman-readable name for the API test
typeYesAPI test type: 'HTTP' or 'MCP'
mcpUrlNoMCP only: the MCP server URL to probe
enabledYesWhether the API test is enabled (scheduled) or paused
httpUrlNoHTTP only: the http(s) URL to probe. Supports {{uuid}}, {{now}}, {{date}}, {{timestamp}}, {{timestampMs}}, {{timestampNs}}, {{randomInt}} and {{traceId}} variables, resolved once per run; write \{{ for a literal {{.
mcpTierNoMCP only: assertion tier — HANDSHAKE, TOOLS_LIST or TOOL_CALL
retriesYesRetries per run before recording a failure (0-5)
httpBodyNoHTTP only: request body
toolNameNoMCP TOOL_CALL tier: name of the tool to invoke
apiTestIdYesId of the API test to update (from list_api_tests or get_api_test)
httpMethodNoHTTP only: request method — GET, POST, PUT, PATCH, DELETE or HEAD
httpHeadersNoHTTP only: request headers, as a name->value map
expectedToolsNoMCP TOOLS_LIST tier: tool names the server must advertise
statusPatternNoHTTP only: status matcher — '200', '2xx' or '20x'
headerMatchersNoHTTP only: response headers that must match, as a name->value map
timeoutSecondsYesPer-run timeout in seconds; positive and not exceeding intervalSeconds
intervalSecondsYesHow often to run the API test, in seconds (minimum 30)
mcpCredentialIdNoMCP only: id of a stored credential
failureThresholdYesConsecutive failing runs before the API test flips to DOWN (1-10)
httpCredentialIdNoHTTP only: id of a stored credential; omit for unauthenticated
maxLatencyMillisNoHTTP only: fail if slower than this many milliseconds
toolArgumentsJsonNoMCP TOOL_CALL tier: JSON object of tool arguments. Supports {{uuid}}, {{now}}, {{date}}, {{timestamp}}, {{timestampMs}}, {{timestampNs}}, {{randomInt}} and {{traceId}} variables, resolved once per run; write \{{ for a literal {{.
bodyValidationTierNoHTTP only: body validation tier — NONE, VALID_JSON, JSON_SHAPE or EXACT_MATCH
mcpMaxLatencyMillisNoMCP only: fail if slower than this many milliseconds
bodyValidationSampleNoHTTP only: sample body for JSON_SHAPE/EXACT_MATCH tiers
mcpResultValidationTierNoMCP TOOL_CALL tier: result validation tier
mcpResultValidationSampleNoMCP TOOL_CALL tier: sample result for JSON_SHAPE/EXACT_MATCH

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed2 schema fields changed
    • changedInput schema / properties / httpUrl / description
      Previous value: -"HTTP only: the http(s) URL to probe"New value: +"HTTP only: the http(s) URL to probe. Supports {{uuid}}, {{now}}, {{date}}, {{timestamp}}, {{timestampMs}}, {{timestampNs}}, {{randomInt}} and {{traceId}} variables, resolved once per run; write \\{{ for a literal {{."
    • changedInput schema / properties / toolArgumentsJson / description
      Previous value: -"MCP TOOL_CALL tier: JSON object of tool arguments"New value: +"MCP TOOL_CALL tier: JSON object of tool arguments. Supports {{uuid}}, {{now}}, {{date}}, {{timestamp}}, {{timestampMs}}, {{timestampNs}}, {{randomInt}} and {{traceId}} variables, resolved once per run; write \\{{ for a literal {{."
  4. Added

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden, and it does so well: it warns that this is a full overwrite and even explains the practical consequence (“pass every field you want to keep”). It also states the return value. It does not mention permissions or side effects beyond overwrite, but the core behavior is transparent.

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?

Three sentences with no filler: the core behavior, the overwrite warning, and the return value are all covered. The most important behavioral caveat is front-loaded, and the schema handles the rest of the parameter detail.

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?

Given the complexity of 27 parameters and no annotations or output schema, the description covers the two things an agent needs beyond the schema: the overwrite semantics and the fact that the full updated test is returned. It could say slightly more about downstream effects, but the key context is present.

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

Parameters3/5

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

The input schema already has 100% description coverage for 27 parameters, so the schema does the heavy lifting. The description adds the useful semantic note that parameters are the same as create_api_test and that omitted values are not kept, but it does not add much per-parameter meaning beyond that.

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 states a specific action on a specific resource: it replaces the entire configuration of an existing API test, identified by apiTestId. It also clearly distinguishes itself from create/delete/enable/disable siblings by emphasizing full overwrite, not a patch.

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 phrase 'existing API test (identified by apiTestId)' makes the update scenario clear, and 'full overwrite, not a partial patch, so pass every field you want to keep' gives concrete usage guidance. It does not explicitly enumerate when-not-to-use alternatives, but the context is strong enough.

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

All Fixter toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources