Skip to main content
Glama

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), its latency (ttfbMillis, totalMillis) and 'timing', which splits the run into its steps (one 'request' step for an HTTP test; for an MCP test, every step of the conversation its protocol and assertion tier define, in order, whether or not the run reached it: initialize, notifications/initialized, tools/list, tools/call (stream first on the 2024-11-05 transport; server/discover instead of the handshake on 2026-07-28)) and each step into dnsMillis, connectMillis, tlsMillis, serverMillis and downloadMillis. A phase the step did not perform is null, a step the run never reached has every phase null, and the first such step is where the run stopped; DNS, connect and TLS on a step mean a new connection was opened for that step (on the 2024-11-05 transport the stream keeps its own connection, so initialize always opens one), and 'remoteAddress' and 'connectionReused' say which address answered and whether the connection was already open. Runs from before this field have 'timing' null. A run also carries 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "apiTestId": "<apiTestId>"
    },
    "name": "get_api_test_runs"
  }
}

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

A3.6/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the bar is lower; the description still adds real substance — RATE_LIMITED runs were not retried and do not count toward uptime, 'timing' is null for older runs, and traceId lets the target's logs be correlated. The gap is that page/size clamping and ordering are left to the schema.

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

Conciseness2/5

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

The core purpose is front-loaded, but the body is a single sprawling sentence with deeply nested parentheticals covering transport-specific step semantics that most callers never need. Substantial protocol-revision detail (2024-11-05 vs 2026-07-28 transports) crowds out the actionable guidance.

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?

With no output schema, the description carries the return-value burden and does so thoroughly: outcome enum, latency fields, per-step phase breakdown, null semantics for unreached steps, connection reuse, and protocol revision fields. Only run ordering and result-count/pagination totals are missing.

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 description coverage is 100% and every parameter (from, to, status, page, size, apiTestId) is documented inline, so the baseline is 3. The description only restates 'filter by time window and status' and 'page through' without adding format or default details beyond the schema.

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?

Opens with a specific verb and resource: 'Page through an API test's recent run history', and states the diagnostic intent ('Use this to investigate why an API test is unhealthy'). It does not name the adjacent tools (get_api_test, get_uptime, list_api_tests) to sharpen the boundary, so it stops short of 5.

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. Optionally filter by time window and status' gives a clear selection context, and the note that raw request/response captures are 'available on the HTTP API only' redirects the agent away from expecting them here. No explicit when-not or named alternatives, so not a 5.

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