Nopaque TotalPath

List Mission Test Configs

listMissionTestConfigs

Read-onlyIdempotent

List saved mission-test configs in your workspace with rich filters. Each saved config is a reusable mission-test definition (name, phone, sector, persona/mission, acceptance criterion, profile, optional tags). Filter by: name (substring), phoneNumber (E.164 exact), sector (e.g. financial-services), profileId, tag (lowercase exact, single tag), createdAfter / createdBefore (ISO8601). Sort by createdAt or name, asc/desc (default createdAt desc). Paginate via cursor + limit (1..100, default 50). Use when: the user wants to find or list configs by attribute ("configs for compliance-EU", "configs for phone +44…", "configs tagged X", "configs created this month"). Returns a slim projection — for full mission/acceptance text use getMissionTestConfig once you have identified the config. Mission configs are immutable today — there is no separate "modified" timestamp. To find configs newly added in a time window, filter by createdAfter / createdBefore. The name filter is case-sensitive: if a name search finds nothing, list without name and look through the names before telling the user a config does not exist. These are NOT standard (scripted) test configs: for those use listTestConfigs. Cross-tool: for the run history launched from a specific config, use listTestRuns?configId=X. For pass-rate-by-config, use aggregateTestRuns?groupBy=configId. Mission configs are workspace-scoped; cross-workspace returns 404.

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": "listMissionTestConfigs"
  }
}

Input Schema

Name	Required	Description	Default
`tag`	No	Only configs carrying this tag. One tag, lowercase, exact match.
`name`	No	Only configs whose name contains this text. Case-sensitive.
`sort`	No	Field to sort by. Defaults to `createdAt`.	createdAt
`limit`	No	Maximum configs to return per page (1-100, default 50). Use `cursor` for the next page.
`cursor`	No	Opaque cursor from `nextCursor` in a previous response.
`sector`	No	Only configs in this sector, for example `financial-services`. Exact match.
`sortDir`	No	Sort direction. Defaults to `desc`.	desc
`profileId`	No	Only configs that use this profile.
`phoneNumber`	No	Only configs that call this number. E.164, exact match, for example `+441234567890`.
`createdAfter`	No	ISO8601 date-time. Only configs created after it.
`createdBefore`	No	ISO8601 date-time. Only configs created before it.

Output Schema

Name	Required	Description	Default
`configs`	Yes
`nextCursor`	No	Opaque base64 cursor for pagination. Absent when no more pages.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds meaningful context beyond that: a slim projection versus full mission text, immutability with no modified timestamp, the workaround of filtering by createdAfter/createdBefore, workspace scoping with 404 on cross-workspace access, and the case-sensitive name trap with a recovery procedure. It stops short of detailing error behavior beyond the 404, hence a 4 rather than 5.

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, then filters, sorting, pagination, usage conditions, return shape, caveats, and cross-tool routing in a logical order. It is dense but every sentence carries operational value; the only waste is slight duplication between the prose filter list and the 100%-covered schema parameters.

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?

An output schema exists, so return values need not be explained, and the description still usefully notes the slim projection and points to getMissionTestConfig for full text. Combined with immutability, workspace scoping, pagination, and sibling routing, an agent has everything needed to call this tool correctly.

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 all eleven parameters are already documented in structured fields; baseline would be 3. The description earns above baseline by restating filter semantics compactly, noting the single lowercase exact-match tag constraint, the default 'createdAt desc' sort, the 1..100 limit with default 50, and by flagging that the name filter is case-sensitive with a fallback strategy. It largely mirrors schema content rather than adding new syntax, so 4 is appropriate.

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 saved mission-test configs'), defines what a saved config contains, and explicitly distinguishes these from standard scripted test configs via 'These are NOT standard (scripted) test configs: for those use listTestConfigs.' An agent can route correctly without opening any 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 an explicit 'Use when' block with concrete user phrasings, and names alternatives for adjacent needs: getMissionTestConfig for full text, listTestRuns?configId=X for run history, aggregateTestRuns?groupBy=configId for pass rates, listTestConfigs for scripted configs. Both when-to-use and when-to-use-something-else are covered.

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.