Nopaque TotalPath

Aggregate Test Runs

aggregateTestRuns

Read-onlyIdempotent

Aggregate test-run counts; groupBy outcome | runType | configId | catalogueTestId | phoneNumber; optional timeBucket day/week/month with UTC ISO8601 bucket keys ("2026-05-12" day, "2026-W19" week, "2026-05" month). Use cases: "% pass/fail this week", "which compliance test fails most", "day-by-day pass count last 2 weeks". ALWAYS use this for "how many", "what share" and "which fails most": counting by paging through listTestRuns gives wrong totals. Filters: runType (mission | compliance | param | load; load = the individual calls load tests made, which are never counted as param), outcome, phoneNumber, configId, catalogueTestId, startedAfter/startedBefore. configId matches the runs of one saved test, standard or mission; there is NO configName filter here, so to count the runs of a named test find its id first (listTestConfigs for a standard test, listMissionTestConfigs for a mission test). With groupBy=configId the keys are ids: name one with getTestConfig (most are standard tests), or getMissionTestConfig if that returns 404. A key of "unknown" means runs with no value for that field. Response capped at top 100 groups by count desc; truncated:boolean indicates cap hit. For whole load tests and their statistics use listLoadTests. D-12: groupBy=stepName returns 400 — for step-level breakdowns within a single run use getRunResults; for step-level aggregation across runs see Phase 1.1.

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": {
      "groupBy": "<groupBy>"
    },
    "name": "aggregateTestRuns"
  }
}

Input Schema

Name	Required	Description
`groupBy`	Yes	Dimension to group counts by. `stepName` is rejected (D-12).
`outcome`	No	Pre-filter runs by outcome before grouping.
`runType`	No	Pre-filter runs by type before grouping. `load` is load-test calls.
`configId`	No	Pre-filter runs launched from a specific saved config before grouping.
`timeBucket`	No	UTC ISO8601 time granularity (Q-5). Omit for flat group counts.
`phoneNumber`	No	Pre-filter runs by destination number (E.164 exact) before grouping.
`startedAfter`	No	ISO8601 lower bound for startedAt (inclusive), applied before grouping.
`startedBefore`	No	ISO8601 upper bound for startedAt (inclusive), applied before grouping.
`catalogueTestId`	No	Pre-filter runs by compliance catalogue test ID before grouping.

Output Schema

Name	Required	Description
`groups`	No	Flat groups sorted by count descending (present when no timeBucket).
`buckets`	No	Time-bucketed groups (present when timeBucket provided). Q-5 UTC ISO8601 keys.
`truncated`	Yes	True when more than 100 unique group keys existed (Q-6 cap hit).
`totalGroups`	Yes	Total distinct group keys before the 100-group cap.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description still adds real behavioral context beyond them: a top-100 group cap with a truncated flag, an "unknown" key for missing field values, and a hard 400 on groupBy=stepName. It does not cover pagination or ordering beyond 'count desc', keeping it short of the top band.

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 purpose and grouping dimensions, then filters, then routing rules — a sensible order with no filler sentences. It is dense to the point of being hard to scan, and internal references like 'D-12' and 'Phase 1.1' are opaque without external context.

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 9-parameter aggregation tool with an output schema, the description covers the cap/truncation semantics, key semantics, and the name-to-id resolution path the agent must take before grouping by configId. Nothing an agent needs in order to call it correctly 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 already 100%, yet the description adds meaning the schema lacks: which runType values mean what (load = individual calls a load test made, never counted as param), that configId matches one saved test's runs and there is no configName filter, and the exact bucket key formats per timeBucket granularity. It does slightly under-explain outcome/phoneNumber pre-filter interaction with bucket keys.

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 (aggregate test-run counts), enumerates the exact groupBy dimensions, and explicitly contrasts itself with listTestRuns for counting. An agent can distinguish it from every listed sibling without opening a schema.

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 explicit when-to-use triggers ('ALWAYS use this for "how many", "what share" and "which fails most"'), explains why the alternative is wrong (paging listTestRuns gives wrong totals), and routes elsewhere for adjacent needs (listLoadTests for whole load tests, getRunResults for step-level, listTestConfigs/getTestConfig for resolving names).

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.