Nopaque TotalPath

Cancel Mapping Job

cancelMapping

DestructiveIdempotent

Cancel an in-progress IVR mapping job. Returns the updated job resource. No effect if the job is already idle/cancelled. Use this when you need to stop a long-running mapping early (e.g., the agent realised the wrong number was supplied).

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

Input Schema

Name	Required	Description	Default
`id`	Yes	Mapping-job identifier.

Output Schema

Name	Required	Description
`id`	Yes	Unique mapping-job identifier.
`name`	Yes	Job display name.
`tags`	No	String labels for filtering and grouping. Lowercase alphanumeric + hyphens.
`error`	No	Error message if the job failed.
`stats`	No	Aggregate statistics for the current run, populated while the job executes.
`config`	Yes	Per-job configuration knobs that govern exploration shape and call orchestration. Sensible defaults are applied server-side when fields are omitted on create.
`status`	Yes	Current job status. Note: mapping jobs typically cycle `running` → `idle` after each run completes — they rarely persist `completed` state.
`userId`	Yes	User who created the job.
`createdAt`	Yes	Creation timestamp.
`runNumber`	No	Flat-merged run number from the active or requested (via `?version=`) run. Phase 04 D-09 — preserved at top level for frontend back-compat alongside the new nested `currentRun` object.
`startedAt`	No	Most-recent run start timestamp.
`updatedAt`	Yes	Last update timestamp.
`currentRun`	No	Nested run summary on single-job responses (Phase 04 D-09 / D-10). Unlike the job-level `status` (which cycles `running` ↔ `idle` and never reaches `completed`), `currentRun.status` CAN reach `completed`/`failed`/`limited`. Read this field to decide whether the discovery is done — do NOT poll for `status === 'completed'` on the job itself. The field name stays `currentRun` even when `?version=N` is supplied — the wrapper describes the run this response describes (active by default, or the historical run identified by `version`).
`completedAt`	No	Most-recent run completion timestamp.
`limitReason`	No	Reason the run stopped early (only present when `status` is `limited`).
`phoneNumber`	Yes	Target phone number in E.164 format.
`workspaceId`	Yes	Owning workspace.
`currentRunId`	No	Identifier of the most-recent run (absent if never started).
`inFlightCount`	No	Currently executing calls.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare destructiveHint=true and idempotentHint=true; the description adds real semantics beyond them by specifying the no-op behavior for already idle/cancelled jobs and the returned resource. It still doesn't say whether partial mapping output is discarded or whether cancellation is final.

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?

Three short sentences, front-loaded with purpose and then behavior and usage; the parenthetical example earns its place by making the trigger scenario concrete. No filler or repetition.

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?

The output schema and the annotations already cover return shape and safety profile, and the description fills in the no-op condition, so an agent can call this confidently. The only gaps are the fate of partially produced mapping data and whether the cancel is irreversible.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a documented uuid `id`, so the schema carries the parameter burden. The description only implies the identifier refers to a mapping job and adds no format or lookup guidance beyond the schema.

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 ("Cancel an in-progress IVR mapping job") plus the return value ("Returns the updated job resource"), which clearly distinguishes it from createMapping/getMapping siblings.

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 condition for use — stopping a long-running mapping early — with a concrete motivating example (wrong number supplied). It does not name an alternative tool or state when not to cancel, so it stops just short of full routing guidance.

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.