Nopaque TotalPath

Run Compliance Test

runComplianceTest

Destructive

Run a compliance test against a phone number. The test calls the number, executes a regulatory probe script (e.g., requests data deletion, asks about AI disclosure), and returns pass/fail per probe. Returns the run resource; poll getRunResults for completion.

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": {
      "phoneNumber": "<phoneNumber>",
      "sector": "<sector>",
      "testIds": "<testIds>"
    },
    "name": "runComplianceTest"
  }
}

Input Schema

Name	Required	Description
`sector`	Yes	Regulatory sector to evaluate against (e.g. `financial-services`, `telco`, `all`). Each `testId` must declare this sector in its catalogue `sectors` array, or be tagged `sectors: [all]`. See `listComplianceCatalogue` for the full set of available sector identifiers and their applicable tests.
`testIds`	Yes	Array of compliance test IDs (one per probe) to run against `phoneNumber`. Each ID corresponds to one entry in `listComplianceCatalogue` (pattern `M-NNN`). Batch size is capped by the workspace tier's `pickerLimit` — see the 402 `BATCH_SIZE_EXCEEDS_TIER` response for the limit.
`phoneNumber`	Yes	Target phone number for the compliance probe, in E.164 format (e.g. `+442012345678`). All `testIds` in the batch are dispatched against this single number.
`carrierRouteId`	No	Bring-your-own-carrier (invite-only). Dial every test in this audit 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. The route sent becomes this number's default, so later audits keep it; omit the key to use the stored default, or pass `null` to dial over nopaque's network and clear the default. An audit with a route dials through it or not at all: if the route cannot be dialled, nothing is run (409, 429 when the trunk has used today's minutes, 403 or 503). Carrier calls are metered as `carrier_compliance`, from answer, and count toward the trunk's daily minutes. Each run records the route as `carrier {integrationId, routeId}`.

Output Schema

Name	Required	Description	Default
`runIds`	Yes
`reportUrl`	Yes	Relative URL of the by-phone aggregator report.

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 destructiveHint=true, openWorldHint=true and non-idempotence; the description adds what those hints actually mean in practice, namely that a real phone is dialled and unwanted real-world actions (e.g. data deletion requests) are performed against the callee. It also discloses the asynchronous run/poll model. It stops short of stating cost/quotas for the run itself (the carrierRouteId schema covers metering only for the BYO-carrier path).

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

Conciseness5/5

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

Three short sentences, front-loaded with the action, then the mechanism, then the polling instruction. No filler and nothing that could be cut without losing information.

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?

With an output schema present, the description need not explain return fields, and it correctly covers the side-effect profile and the async completion path. Only minor gaps remain, such as whether runs are billed or how partial failures surface, which are partly handled in-schema.

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 description coverage is 100% and each parameter is richly documented in-schema, so the description adds little parameter meaning beyond noting probes run per testId and all tests hit a single number. That is consistent with the baseline 3 when the schema already carries the semantics.

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+resource (run a compliance test against a phone number) and explains the mechanism: it dials the number, executes a regulatory probe script such as data-deletion requests or AI-disclosure questions, and reports pass/fail per probe. That is enough to distinguish it from retrieval siblings like getRunResults, listComplianceReports, or the mission/digital test variants.

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?

Explicitly routes the agent after invocation: "Returns the run resource; poll getRunResults for completion," which names the correct follow-up sibling. It does not state when to prefer this over runMissionTest or getComplianceReportByPhone, but it gives clear operating context for the call itself.

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.