Nopaque TotalPath

Get Mission Test Config

getMissionTestConfig

Read-onlyIdempotent

Get a single saved mission-test config by ID. Returns the full row: name, description, phoneNumber, sector, mission, acceptance, profileId, tags, createdAt, updatedAt. Use when: you have a config ID (typically from listMissionTestConfigs or from a run.configId field) and want to inspect the persona / mission / acceptance criterion text — for example before launching a new run or to explain to the user how a previous run was configured. Cross-tool: for run history launched from this config, use listTestRuns?configId=X. For the run that produced a specific verdict, use getMissionTestRun. Configs are editable via PATCH /testing/mission-test-configs/{id}; updatedAt reflects the most recent edit and may differ from createdAt. 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": "getMissionTestConfig"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Mission test config identifier.

Output Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`tags`	No	Optional, lowercase, dash-or-alphanumeric workspace-scoped tags. Up to 10. Use the listMissionTestConfigs ?tag= filter to find configs by tag (single-tag exact match).
`sector`	Yes
`mission`	Yes
`voiceId`	No	Telnyx voice id for the call, from the operator-enabled catalogue (`GET /testing/voices`). Omit to use the configured default voice.
`language`	No	The call language. Absent means English.
`createdAt`	Yes
`createdBy`	No	Set only on a config created by a sheet import (`POST /imports/{id}/commit`): the id of the person whose commit created it. Absent on configs created any other way.
`profileId`	Yes
`updatedAt`	Yes
`acceptance`	Yes
`description`	No
`phoneNumber`	Yes
`workspaceId`	Yes
`advancedParams`	No	Optional per-call turn-detection overrides. Absent means mission-tester keeps its env-var defaults.
`carrierRouteId`	No	Bring-your-own-carrier (invite-only). Dial this config's runs 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 mission with a route dials through it or not at all: if the route cannot be dialled when the run starts, the run is refused and the number is never called normally. It is checked when the config is saved and resolved again at every launch. Carrier calls are metered as `carrier_s2stest`, from answer, and count toward the trunk's daily minutes.
`backgroundNoise`	No	Caller background noise played under the call. Omit for none.
`maxDurationSecs`	No	Optional per-call duration cap in seconds. Omit to use the server default for the mission kind (freeform 180s, compliance 90s). Raise it for flows that collect a lot of data — a booking that needs name, date of birth, location and eligibility will not finish in 180s. Up to 1800 (30 minutes).

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 readOnly, idempotent, non-destructive, closed-world, so the safety bar is low; the description still adds real behavior: the record is editable via PATCH /testing/mission-test-configs/{id}, updatedAt reflects the most recent edit and may differ from createdAt, and cross-workspace access returns 404. That 404 and edit-history detail are genuine value beyond the annotations, though return-shape and error handling beyond 404 are not covered.

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 usage, then cross-tool routing — a sensible order with no filler sentences. It is dense and slightly over-packed (field enumeration plus PATCH path plus 404 note), but each clause carries real information.

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-item read with one required param, annotations and an output schema already in place, the description covers everything needed: what it returns, when to call it, sibling alternatives, mutability of the underlying row, and the main failure mode (404 across workspaces).

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% for the single `id` param, so baseline would be 3. The description adds meaning by explaining where the ID typically comes from (a prior list call or a run.configId field), which helps the agent source the argument correctly, and it implies IDs are workspace-scoped via the 404 note.

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 (Get) and resource (a single saved mission-test config) scoped by ID, then enumerates the returned fields so the agent knows exactly what it retrieves. It distinguishes itself from listMissionTestConfigs (which supplies the ID) and getMissionTestRun (which returns run data) by name.

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?

Explicit 'Use when' clause names the prerequisite (you have a config ID) and even the typical provenance of that ID (listMissionTestConfigs or a run.configId field). Cross-tool routing is spelled out: listTestRuns?configId=X for run history, getMissionTestRun for the run behind a verdict.

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.