Nopaque TotalPath

Draft Mission Test Configs in a Batch

draftMissionTestConfigBatch

Read-onlyIdempotent

Check up to 25 NEW mission-test configs at once without saving them. Takes drafts: an array of objects, each with the same fields as draftMissionTestConfig. Returns results, one per draft in the same order, each exactly what draftMissionTestConfig returns for it: the config as it would be stored and problems (invalid fields, a phone number the dial policy blocks, a caller persona that no longer exists). An item that is not an object gets the problem "Each draft must be an object." Nothing is saved or changed, so it is safe to call repeatedly. Use when: you have several tests to check, for example rows read from a sheet with getImportRows. 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": {
      "drafts": "<drafts>"
    },
    "name": "draftMissionTestConfigBatch"
  }
}

Input Schema

Name	Required	Description	Default
`drafts`	Yes	Up to 25 new mission test configs, each the same shape as the create body. An item that is not an object is answered with a problem rather than refused.

Output Schema

Name	Required	Description	Default
`results`	Yes	One result per draft, in the order sent. Each is exactly what `POST /testing/mission-test-configs/draft` answers for that draft.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive, and the description reinforces this with the reason ('Nothing is saved or changed, so it is safe to call repeatedly'). It adds genuinely behavioral detail beyond annotations: per-item error handling ('An item that is not an object gets the problem ...'), result ordering, and what kinds of problems surface (invalid fields, blocked phone number, missing persona).

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 the capability and scope, then return shape, then usage. Dense and largely waste-free, though the enumeration of problem types and the parenthetical about storage repeat ground already implied earlier in the same paragraph.

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-parameter, non-destructive batch tool with an output schema and full annotation coverage, the description covers scope, per-item semantics, failure handling, ordering, and the save boundary. Nothing an agent needs to invoke 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 100%, so the baseline is 3, but the description adds real meaning: the array elements share the same shape as draftMissionTestConfig's create body, and malformed items are answered rather than rejected. That clarifies an unusual per-item contract the schema only hints at.

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 ('Check'), resource ('mission-test configs'), and batch scope ('up to 25 ... at once without saving'). It explicitly ties itself to the singular sibling by saying each result is 'exactly what draftMissionTestConfig returns for it', so an agent can distinguish batch from single 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 'Use when' clause with a concrete scenario ('several tests to check, for example rows read from a sheet with getImportRows') and clarifies that saving is a separate app step. It stops short of an explicit when-not statement pointing at draftMissionTestConfig for single-item checks, but the batch framing implies it.

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.