Skip to main content
Glama

Fixter

by dev.fixter.mcp
OverviewDiscussionsAdmin

Get API Test Runs

get_api_test_runs
Read-onlyIdempotent

Page through an API test's recent run history — each run's outcome (SUCCESS, FAILURE, ERROR, MISSED, RATE_LIMITED), timing, any assertion failures and its traceId: the W3C trace id the probe sent to the target as a traceparent header, so the target's own logs and traces for that run can be found by trace_id. A RATE_LIMITED run means the target answered HTTP 429 to the monitor: the run was not retried, the next run was deferred by the target's Retry-After (retryAfterSeconds), and it does not count toward uptime. For MCP tests, 'protocolRevision' is the protocol revision that run spoke, and 'previousRevision' is set when a NEWEST_SUPPORTED test moved to a newer revision in that run. Use this to investigate why an API test is unhealthy. Optionally filter by time window and status. The redacted request/response capture of each run is available on the HTTP API only.

Input Schema

NameRequiredDescriptionDefault
toNoEnd of the window, ISO-8601 instant (inclusive)
fromNoStart of the window, ISO-8601 instant e.g. '2026-07-01T00:00:00Z' (inclusive)
pageNoZero-based page number (default 0)
sizeNoRuns per page — default and max 200; values outside 1-200 are clamped
statusNoFilter to one outcome: SUCCESS, FAILURE, ERROR, MISSED or RATE_LIMITED
apiTestIdYesId of the API test whose runs to fetch

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / status / description
      Previous value: -"Filter to one outcome: SUCCESS, FAILURE, ERROR or MISSED"New value: +"Filter to one outcome: SUCCESS, FAILURE, ERROR, MISSED or RATE_LIMITED"
  2. Changed4 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / format
      Added value: +"int32"
    • addedInput schema / properties / size / format
      Added value: +"int32"
  3. Added
  4. Removed
  5. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already make the read-only, idempotent, non-destructive profile clear, and the description adds substantial semantics on top: RATE_LIMITED means HTTP 429, no retry occurred, Retry-After is honored (retryAfterSeconds), and the run is excluded from uptime. It also explains traceId as the W3C traceparent value for cross-referencing target-side logs, and protocolRevision/previousRevision semantics for MCP tests.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the traceId payoff are front-loaded, and nearly every clause carries information an investigator needs. The middle is dense with parenthetical clauses, making some sentences long, but there is no filler.

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?

There is no output schema, so the description carries the return-value burden and does so: it enumerates outcomes, timing, assertion failures, traceId, retryAfterSeconds, and the MCP revision fields. It also discloses the one hard limitation (captures available on the HTTP API only), leaving nothing critical unstated for a paginated read tool.

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?

With 100% schema coverage, the schema already documents from/to/page/size/status/apiTestId, so the baseline is 3. The description adds value by framing the filters as an optional time window and status, and by defining what each outcome status actually means; it also flags the important scope limit that request/response captures are not exposed here.

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?

States a specific verb and resource ('Page through an API test's recent run history') plus the identity of the parent entity (apiTestId). It is clearly distinct from siblings like get_api_test (config) and get_uptime (aggregate), and it names its investigative purpose explicitly.

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?

"Use this to investigate why an API test is unhealthy" gives a concrete trigger, and the description notes optional filtering by time window and status. It stops short of naming alternatives (e.g., use get_uptime for aggregate availability, get_api_test for configuration), so the routing is implied rather than stated.

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