Nopaque TotalPath

List Test Runs

listTestRuns

Read-onlyIdempotent

List test runs (mission/compliance/standard/param) with rich filters: runType, outcome (PASS/FAIL/ERROR/INCONCLUSIVE), phoneNumber, configId, catalogueTestId, configName / configPhoneNumber (standard and param runs only: case-insensitive substring of the test name or run id, substring of the number it dials), date range (startedAfter/startedBefore), sort (startedAt/completedAt asc/desc), and cursor pagination. Use cases: "last 3 mission failures", "runs against phone +44… this week", "compliance fails in the last 24h", "latest run of the standard test called X" (use configName). There are two kinds of saved test: standard tests (listTestConfigs) and mission tests (listMissionTestConfigs). configId matches the runs of one saved test of either kind. configName never matches a mission test: if it finds nothing, look the test up in listMissionTestConfigs and filter by configId before telling the user a test has no runs. Rows carry ids, not test names: use getTestConfig or getMissionTestConfig to name one. For counts and percentages use aggregateTestRuns instead, never by paging through this list. D-11: Load tests live in a separate table — use listLoadTests; runType=load returns 400 here.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "listTestRuns"
  }
}

Input Schema

Name	Required	Description	Default
`jobId`	No	Legacy back-compat filter — list runs for a specific test job.
`limit`	No	Maximum runs to return per page (1-200, default 50). Use `cursor` for the next page.
`cursor`	No	Opaque base64 pagination cursor from `nextCursor` in a previous response.
`sortBy`	No	Timestamp field to sort by. Defaults to `startedAt`.	startedAt
`outcome`	No	Filter by outcome.
`runType`	No	Filter by run type. `load` is rejected (D-11).
`sortDir`	No	Sort direction. Defaults to `desc` (newest first).	desc
`configId`	No	Filter by saved config UUID. Matches runs of a mission-test config and runs of a standard or param test config.
`configName`	No	Only standard and param runs whose test name contains this text, or whose run ID does. Case-insensitive. Does not match mission or compliance runs.
`phoneNumber`	No	E.164 phone number filter.
`startedAfter`	No	ISO8601 lower bound for startedAt (inclusive).
`startedBefore`	No	ISO8601 upper bound for startedAt (inclusive).
`catalogueTestId`	No	Filter by compliance catalogue test ID.
`configPhoneNumber`	No	Only standard and param runs whose test dials a phone number containing this text.

Output Schema

Name	Required	Description	Default
`runs`	Yes
`nextCursor`	No	Opaque base64 cursor; present only when more pages are available.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds behavior the annotations cannot: runType=load is rejected with 400 (D-11), configName silently excludes mission tests, and rows carry ids rather than names so getTestConfig/getMissionTestConfig must be called to name one. These are exactly the traps an agent would otherwise hit.

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?

Front-loaded with the verb and filter surface, then use cases, then the operational gotchas — a sensible order. The initial list of filters (runType, outcome, phoneNumber, configId, catalogueTestId, dates, sort, cursor) duplicates schema properties and is the one section that does not fully earn its length.

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?

For a 14-parameter list tool with an output schema and full annotation coverage, the description supplies everything else an agent needs: which sibling handles counts, which handles load tests, how to resolve ids to names, and how to recover from a configName miss. Nothing material is missing.

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 baseline is 3, and the description still adds meaning beyond it: configId matches both mission and standard/param configs, configName is a case-insensitive substring over test name or run id and never matches mission tests, and configPhoneNumber is a substring of the dialed number. The opening filter enumeration largely restates schema fields, so it stops short of a 5.

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 ('List test runs') plus the run types covered (mission/compliance/standard/param) and the filter surface. It actively distinguishes itself from siblings by naming aggregateTestRuns for counts, listLoadTests for load tests, and listMissionTestConfigs/listTestConfigs for the saved-test side.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives four concrete use-case phrasings ('last 3 mission failures', 'runs against phone +44… this week', etc.), explicit when-not guidance ('for counts and percentages use aggregateTestRuns instead, never by paging through this list'), and a recovery path when configName returns nothing. It even routes load tests elsewhere with the exact error symptom (400).

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

All Nopaque TotalPath tools Inspect

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.