Nopaque TotalPath

Get Test Config

getTestConfig

Read-onlyIdempotent

Get a single saved standard (scripted) test config by ID: name, description, phoneNumber, language, type and its steps (each step has a name, the action taken, the expected transcript and the pass threshold). Use when: you have a config ID (from listTestConfigs, or the configId key of an aggregateTestRuns group, or testConfigId on a run) and want its name or to explain what the test checks. For mission-test configs use getMissionTestConfig. Cross-workspace returns 404.

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": {
      "id": "<id>"
    },
    "name": "getTestConfig"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Test config identifier.

Output Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`type`	No	`standard` runs the steps as-is; `parameterized` requires `requiredParameters` filled at run-time (sweep / batch dispatchers supply them).
`steps`	Yes
`version`	Yes	Bumped on every update — clients can use for optimistic concurrency.
`language`	No	Transcription language the config's calls are transcribed in. Resolved to `en-GB` when the config was created without one, so every config created since the field existed carries a value; configs saved before it have none, which also means `en-GB`.
`createdAt`	Yes
`createdBy`	Yes	User ID of the creator.
`profileId`	No	Voice / data profile for `standard` configs only. Omitted for `parameterized`.
`updatedAt`	Yes
`scheduleId`	No	Schedule that triggers automated runs (use `template:<id>` to create from a built-in template).
`description`	No
`phoneNumber`	Yes	E.164-formatted phone number the test calls.
`workspaceId`	Yes
`carrierRouteId`	No	Bring-your-own-carrier (invite-only). Dial this config's calls through one of the workspace's carrier routes, over the workspace's own SIP trunk, instead of nopaque's network. Carrier routes are set up with nopaque. A config with a route dials through it or not at all: if the route cannot be dialled when a run starts, the run is refused and the number is never called normally. A refused `POST /testing/runs` returns 409 (or 503); a scheduled run, batch or sweep records a failed run whose `errorMessage` says why; a load test fails before it starts. Carrier calls are metered as `carrier_testing` (load tests: `carrier_load_testing`), not `testing`. Omitted when the config dials normally.
`backgroundNoise`	No	Caller background noise played under the call. Omit for none.
`maxDurationSecs`	No	Whole-call ceiling in seconds. When omitted the tester applies its own default of 300. Every `hold` step's `durationSecs` must fit inside it.
`patternSettings`	No	Load-test failure-pattern thresholds and re-prompt phrases for this IVR. Omit for the platform defaults.
`requiredParameters`	No	Required parameter labels for `parameterized` configs only.

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety needs no restating. The description does add beyond them by disclosing an edge case the annotations cannot express: cross-workspace access returns 404. It stops short of describing pagination or size limits, but neither applies to a single-record fetch.

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?

It is front-loaded with the action and its payload, then usage, then the sibling redirect and the 404 caveat, all in three sentences with no filler. The field enumeration partly duplicates what the output schema already exposes, which is the only mild redundancy.

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 single-record read with full annotation coverage and an output schema, the description supplies everything else an agent needs: what comes back, when to call it, how to obtain the ID, which sibling to use instead, and the cross-workspace failure mode. Nothing material is left unstated.

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 one parameter at 100% schema coverage, the schema already documents the UUID format, so baseline is 3. The description compensates by explaining provenance of the ID value – where an agent can obtain it (listTestConfigs, aggregateTestRuns configId key, testConfigId on a run) – which is meaning the schema does not carry.

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?

The description opens with a specific verb and resource ("Get a single saved standard (scripted) test config by ID") and enumerates the fields returned, including step structure. It also names the sibling it excludes (getMissionTestConfig), so an agent can distinguish it from the mission/digital variants without opening either 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?

It gives an explicit "Use when" clause with three concrete sources for the required ID (listTestConfigs, the configId key of an aggregateTestRuns group, testConfigId on a run) plus the intent that selects this tool (want the name or to explain what the test checks). It also redirects mission-test lookups to getMissionTestConfig, so both the when-to-use and the alternative are stated.

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.