Nopaque TotalPath

Draft Mission Test Config

draftMissionTestConfig

Read-onlyIdempotent

Check a NEW mission-test config without saving it. Takes the same fields as creating one (name, phoneNumber in E.164, sector, mission, acceptance, profileId, optional description, tags, maxDurationSecs, voiceId, backgroundNoise (caller background noise: cafe, street, home or wind; absent means none), advancedParams, language (the call language: en, multi, es, fr, de, it, pt, nl, hi, ru or ja; absent means English); profileId is a caller persona id from listProfiles) and returns the config as it would be stored plus problems: every failed check at once (invalid fields, a phone number the dial policy blocks, a caller persona that no longer exists). Nothing is saved or changed, so it is safe to call repeatedly. Use when: the user wants to set up a new test and you want to check it before they save it. Saving is a separate step the user takes in the app.

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": {
      "name": "<name>",
      "phoneNumber": "<phoneNumber>",
      "sector": "<sector>",
      "mission": "<mission>",
      "acceptance": "<acceptance>",
      "profileId": "<profileId>"
    },
    "name": "draftMissionTestConfig"
  }
}

Input Schema

Name	Required	Description
`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	Optional language the call is held in. Omit for English, which is how every mission test has behaved to date. Use `multi` when the IVR may start in English and switch.
`profileId`	Yes
`acceptance`	Yes
`description`	No
`phoneNumber`	Yes
`advancedParams`	No	Optional per-call turn-detection overrides. Omit to keep the server's env-var defaults, which is how every mission test has behaved to date.
`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 (400 when it cannot be dialled, 503 when it could not be looked up) 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).

Output Schema

Name	Required	Description	Default
`config`	Yes	The config as it would be stored, without `id`, `workspaceId` or timestamps. A field that passed its check is shown as it would be stored (tags normalised); one that failed is left as sent; one that was not sent is left out.
`problems`	Yes	Every check that failed. Empty when the config could be saved as sent.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description nonetheless adds real behavior: the return is the config as it would be stored plus a `problems` collection that aggregates every failed check at once (invalid fields, dial-policy-blocked numbers, vanished caller personas). That tells the agent validation failures come back as data rather than as a thrown error, which is information an agent cannot get from the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded and nearly every clause carries information, but the core is a single sprawling sentence with nested parentheticals covering backgroundNoise, language and profileId, which makes it harder to parse than a short bulleted field list would be. A few phrases repeat schema-documented details (E.164, the language value list) that could have been trimmed to make room for carrierRouteId.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, non-mutating validation tool with an output schema and full annotations, the description covers purpose, safety, validation semantics and most field meanings. The missing coverage of carrierRouteId — a bring-your-own-carrier route with its own 400/503 failure modes — is the one substantive gap for a caller assembling a full config.

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 only 50% schema description coverage across 14 parameters, the description carries a lot: it enumerates the required fields, specifies E.164 for phoneNumber, defines profileId as a caller persona `id` from listProfiles, lists the language enum values and the 'absent means English' default, and spells out backgroundNoise options and their meaning. The one notable omission is carrierRouteId, which exists in the schema but is never mentioned in the description.

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: 'Check a NEW mission-test config without saving it', and immediately qualifies it as taking 'the same fields as creating one'. The emphasis on NEW, together with the explicit 'nothing is saved', separates it from retrieval siblings like getMissionTestConfig and from change-drafting tools 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 Guidelines4/5

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

Gives an explicit when-to-use trigger ('the user wants to set up a new test and you want to check it before they save it') and clarifies the boundary that saving is a separate in-app step. It does not name an alternative tool such as draftMissionTestConfigChange or create-equivalent, so the sibling routing is implied by 'NEW' rather than 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.