Nopaque TotalPath

Send a Verification Code to a Human's Mobile

requestAnchorCode

Send a one-time code by SMS to a human's mobile phone, to verify that a real person stands behind this workspace. This is what unlocks calling capacity. The code goes to the PHONE, not to you. You then need to ask that person what the code says and pass it to verifyAnchorCode.

USE WHEN:
- You have just called registerWorkspace and the workspace has no capacity yet
- A person has agreed to be the accountable human for this workspace and has given you their mobile number

THE HUMAN'S PART:
Before calling this, tell the person that a text message is about to arrive and that you will need them to read the code back to you. Ask for the number in international format with the country code, for example +447700900123 or +12025550123.

ARGUMENTS:
- phoneNumber: the mobile number in E.164 format (a plus sign, country code, then digits, no spaces). Must be a MOBILE in the United Kingdom, Guernsey, Jersey, the Isle of Man or the United States. Landlines cannot receive the code.

RESPONSE:
- 202 with sent: true. The code is on its way. Now ask the person for it and call verifyAnchorCode with the same phoneNumber.

WHEN IT IS REFUSED:
- reason country_not_supported: only the countries above can be used
- reason not_a_mobile: the number is a landline or similar
- reason unparseable: check the format
- reason anchor_limit_reached (403): this workspace already holds the maximum number of verified humans. Waiting will not help. One of them has to be replaced first, which a person does from workspace settings. Note this is not returned when you re-request a code for a number this workspace already holds: that resend is always allowed, and it is what to do if a verifyAnchorCode retry told you the code had expired.
- reason already_anchored (409): that number is already the verified human for a different workspace. A number can stand behind one workspace at a time.
- 429 with retryAfterSeconds: too many codes this hour. Wait; do not resend in a loop. Each request sends a real text message to a real person.
- 403: this workspace has requested too many codes in its lifetime and will not be sent another.

RELATED TOOLS:
- verifyAnchorCode: submit the code the person read to you
- registerWorkspace: if you have no key yet

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>"
    },
    "name": "requestAnchorCode"
  }
}

Input Schema

Name	Required	Description	Default
`phoneNumber`	Yes	The mobile number to send the code to, in E.164 format, for example +447700900123. UK, Channel Islands, Isle of Man or US mobiles only.

Output Schema

Name	Required	Description	Default
No arguments

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 declare openWorldHint=true, idempotentHint=false and destructiveHint=false, and the description goes well beyond them: it discloses that each call sends a real SMS with real-world cost, hourly 429 limits with retryAfterSeconds, lifetime 403 limits, and a full enumeration of refusal reasons including the subtle 'resend is always allowed' carve-out. It stops short of describing the response payload beyond the 202/sent:true case, but that is covered by the output schema.

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?

The content is long but well structured with front-loaded intent followed by USE WHEN, ARGUMENTS, RESPONSE, refusal reasons and related tools. There is mild redundancy between the opening 'ask that person what the code says' and the RESPONSE section repeating the same instruction, but for a multi-error-path flow the length is largely earned.

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 one-parameter, side-effecting external tool with an output schema, this covers everything an agent needs: prerequisites, human interaction script, format rules, success response, and every documented failure mode with the correct recovery action. Remaining detail about the response body is carried by the output schema.

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% and the schema already states E.164 format and the supported countries, so the baseline is 3. The description adds genuine meaning on top: landlines cannot receive the code, mobile-only restriction, and the requirement to ask the human for the number in international format — details that change how the agent collects the value.

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?

The opening sentence names a specific verb and resource (send a one-time SMS code to a human's mobile) and immediately states the underlying goal (verifying a real person to unlock calling capacity). It explicitly distinguishes the phone from the agent ('The code goes to the PHONE, not to you') and routes to the sibling verifyAnchorCode for the next step.

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?

A dedicated USE WHEN block gives two concrete preconditions (just called registerWorkspace with no capacity; a person has agreed and supplied a number). Alternatives are named explicitly: verifyAnchorCode for submitting the code, registerWorkspace if no key exists.

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.