Skip to main content
Glama

Fixter

by dev.fixter.mcp
OverviewDiscussionsAdmin

create_api_test

Define an API test — a scheduled test of a production HTTP endpoint or MCP server: request + assertions (status/latency/headers/body or MCP tier) executed on an interval, tracking uptime and correctness. Use this to start watching an HTTP endpoint or an MCP server. Set type="HTTP" and the httpTarget/statusPattern params for a web endpoint, or type="MCP" and the mcpTarget params for an MCP server. The URL, headers, body and MCP tool arguments accept Postman-style variables that are resolved once per run: {{uuid}}, {{now}} (ISO 8601 UTC), {{date}}, {{timestamp}} (Unix seconds), {{timestampMs}}, {{timestampNs}}, {{randomInt}} (0-1000) and {{traceId}} (the run's W3C trace id, also sent as the traceparent header). Unknown names are left as written; write {{ for a literal {{. Returns the created API test, including its generated id and current state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesHuman-readable name for the API test, e.g. 'checkout API health'
typeYesAPI test type: 'HTTP' for a web endpoint, 'MCP' for an MCP server
mcpUrlNoMCP only: the MCP server URL to probe
enabledYesWhether the API test starts 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 depth — HANDSHAKE (just connect), TOOLS_LIST (check expectedTools are advertised) or TOOL_CALL (invoke a tool)
retriesYesRetries per run before recording a failure (0-5)
httpBodyNoHTTP only: request body to send; takes the same variables as the URL
toolNameNoMCP TOOL_CALL tier: name of the tool to invoke
httpMethodNoHTTP only: request method — GET, POST, PUT, PATCH, DELETE or HEAD
httpHeadersNoHTTP only: request headers to send, as a name->value map; values take the same variables as the URL
expectedToolsNoMCP TOOLS_LIST tier: tool names the server must advertise
statusPatternNoHTTP only: expected status matcher — 3 chars, digits or 'x' wildcards. '200' matches exactly 200; '2xx' matches any 2xx; '20x' matches 200-209
headerMatchersNoHTTP only: response headers that must match, as a name->value map
timeoutSecondsYesPer-run timeout in seconds; must be positive and not exceed intervalSeconds
intervalSecondsYesHow often to run the API test, in seconds (minimum 30)
mcpCredentialIdNoMCP only: id of a stored credential to authenticate the MCP session
failureThresholdYesConsecutive failing runs before the API test flips to DOWN (1-10)
httpCredentialIdNoHTTP only: id of a stored credential to authenticate the request (from list_api_test_credentials); omit for an unauthenticated call
maxLatencyMillisNoHTTP only: fail if response takes longer than this many milliseconds
toolArgumentsJsonNoMCP TOOL_CALL tier: JSON object of arguments to pass to the tool. 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 the API test takes longer than this many milliseconds
bodyValidationSampleNoHTTP only: sample body for JSON_SHAPE (a shape template) or EXACT_MATCH tiers
mcpResultValidationTierNoMCP TOOL_CALL tier: result body validation tier — NONE, VALID_JSON, JSON_SHAPE or EXACT_MATCH
mcpResultValidationSampleNoMCP TOOL_CALL tier: sample result for JSON_SHAPE/EXACT_MATCH validation

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed4 schema fields changed
    • changedInput schema / properties / httpBody / description
      Previous value: -"HTTP only: request body to send"New value: +"HTTP only: request body to send; takes the same variables as the URL"
    • changedInput schema / properties / httpHeaders / description
      Previous value: -"HTTP only: request headers to send, as a name->value map"New value: +"HTTP only: request headers to send, as a name->value map; values take the same variables as the URL"
    • 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 arguments to pass to the tool"New value: +"MCP TOOL_CALL tier: JSON object of arguments to pass to the tool. 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 provided, the description carries the full burden of behavioral disclosure, and it does so well: it explains that variables are resolved once per run, unknown names are left as written, and how to escape a literal '{{'. It also discloses that the tool returns the created test with its id and state. It does not mention idempotency or side effects, but 'create' and 'returns the created API test' make the mutating nature clear.

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 front-loaded with the core action and purpose, then moves to usage mode selectioncars. The variable list is long but necessary for this tool's correct use)Skip. Every sentence earns its place, and there is no filler or repetition of schema content.

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 26 parameters, no annotations, and no output schema, the description provides a solid overall picture: what a test is, how to select HTTP vs MCP mode, variable resolution behavior, and what is returned. It does not exhaustively map every parameter dependency (e.g., when mcpTier/toolName are required together), but the schema already covers those details. The description is complete enough for an agent to form a correct mental model.

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?

Schema coverage is 100%, so the baseline is 3. The description adds valuable cross-parameter semantics (variable interpolation behavior, the HTTP/MCP mode split), but it contains an inaccuracy: it refers to 'httpTarget' while the actual property is 'httpUrl'. This minor error slightly undermines parameter guidance, so it stays at baseline rather than earning a 4.

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 clearly states a specific action ('Define an API test'), defines what the test is (scheduled probe of an HTTP endpoint or MCP server), and distinguishes this creation tool from siblings like update_api_test, delete_api_test, and list_api_tests. The first sentence alone tells the agent what resource this operates on and what it accomplishes.

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 clear usage context: 'Use this to start watching an HTTP endpoint or an MCP server' and conditions for HTTP vs MCP mode with concrete parameter pointers. It does not explicitly name alternatives for modification/deletion (update_api_test, delete_api_test), but the create-vs-manage distinction is strongly implied by the tool name and the 'start watching' framing.

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