Skip to main content
Glama
Sign In

Nopaque TotalPath

by uk.co.nopaque
OverviewDiscussionsAdmin

Verify the Code and Unlock Calling Capacity

verifyAnchorCode
Idempotent

Submit the code the human read to you from their text message. On success the number is permanently recorded as this workspace's accountable human, and the workspace receives its free calling capacity, so it can now run createMapping, runMissionTest and runComplianceTest.

USE WHEN:
- You called requestAnchorCode and the person has told you the code

ARGUMENTS:
- phoneNumber: the SAME number you passed to requestAnchorCode, in the same E.164 format
- code: the digits from the text message, exactly as the person read them

RESPONSE ON SUCCESS (200):
- anchored: true. The human is verified.
- freeGrantOutcome tells you about capacity:
  - granted: free capacity was added. You can start work. Call getWorkspaceUsage to see how much.
  - already-granted: this workspace already had it. Nothing is wrong.
  - not-owed: this number has already used its one free allocation, on this or another workspace. The human is verified, but capacity has to be bought. Call getClaimLink so the person can pay.
  - unavailable: the code was RIGHT and the human is verified, but the capacity grant could not be completed just now. Nothing is lost and nothing is double-spent. Wait a minute and call verifyAnchorCode again with the same arguments. If that retry is refused with reason bad_code, the code has expired, NOT been misread: do not ask the person to check it. Call requestAnchorCode for a fresh code and verify again; the grant is retried on that verification.
  - refused: the grant was declined. Tell the person and call getClaimLink.

WHEN IT IS REFUSED:
- reason bad_code (400): the code did not match, or has expired. Codes expire after a few minutes. If the person only just read it, ask them to check it and try once more; otherwise call requestAnchorCode for a fresh one. If you are retrying after an unavailable outcome, treat bad_code as expired.
- reason already_anchored (409), or anchor_limit_reached (403): see requestAnchorCode
- reason not_held (409): the number you passed as replaces is not one of this workspace's verified humans. Do not guess at it.
- reason replaces_unparseable (400): the replaces number is not a number we can read. Ask the person to give it in full international format.
- reason survivor_is_target (400): replaces named the SAME number being verified, which would leave the workspace with nobody accountable.
- A 5xx means the verification provider had a problem, never that the code was wrong. Try again shortly.

RELATED TOOLS:
- getWorkspaceUsage: see the capacity you now have
- getClaimLink: let the human take ownership and buy more
- createMapping, runMissionTest, runComplianceTest: the work itself

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

Input Schema

NameRequiredDescriptionDefault
codeYesThe one-time code from the text message, as digits.
replacesNoOptional, in E.164 format. Use ONLY when this person is taking over from someone whose number is already the verified human for this workspace — a colleague who has left, say. The new number is anchored and the old one freed in one step, so the workspace is never left without an accountable person. Omit it to ADD a verified human alongside the existing ones, which is what you usually want.
phoneNumberYesThe same number the code was sent to, in E.164 format.

Output Schema

NameRequiredDescriptionDefault
anchoredYes
freeGrantedYesCapacity was added to the workspace by THIS call.
freeGrantOwedYesTrue when this anchor entitled the workspace to its free grant at the moment of anchoring, i.e. the grant was asked for on this call. False when the number had already spent its one allocation.
freeGrantErrorNoPresent only for `refused` (auth's reason, e.g. `not-an-agent-workspace`) and `unavailable` (the literal `unavailable`).
freeGrantOutcomeYes`granted`: capacity added now. `already-granted`: the workspace already held it from an earlier call; nothing is wrong. `not-owed`: this number spent its one allocation before, on this workspace or another. `refused`: auth declined (see `freeGrantError`). `unavailable`: auth could not be reached or answered in time; the anchor stands, retry the grant by verifying again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag this as a non-read-only, idempotent, externally-touching operation, and the description adds substantial context beyond them: the permanence of the anchoring, the one-time nature of the free allocation, the fact that retrying with identical arguments is safe, and how to read 5xx responses. The idempotentHint is actively supported by the retry guidance.

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 description is long but front-loaded and organized into USE WHEN, ARGUMENTS, RESPONSE, refusals, and related tools, with the success path before the error taxonomy. Some of the freeGrantOutcome explanation overlaps the output schema, and the failure reasons for replaces appear without that parameter being listed in ARGUMENTS.

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 multi-outcome mutation tool with a branching response, the description covers the success cases, every documented refusal reason, retry semantics, and sibling routing. Even though an output schema exists, the decision rules mapping freeGrantOutcome values to next actions are necessary and present.

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: phoneNumber must be the SAME value previously sent to requestAnchorCode, and code must be transcribed exactly as the person read it. It also documents the failure semantics of the replaces parameter, though replaces is missing from the ARGUMENTS list, leaving a small structural gap.

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 description states a specific verb and resource ('submit the code the human read'), names the preceding step (requestAnchorCode), and describes the permanent effect on the workspace. An agent can distinguish this from requestAnchorCode and getClaimLink without opening any schema.

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?

There is an explicit USE WHEN condition tied to the sibling requestAnchorCode, plus branch-by-branch routing: getClaimLink for not-owed/refused, requestAnchorCode for expired codes, and a specific rule for retrying after an 'unavailable' outcome. When-to-use, when-not-to-use, and alternatives are all present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Nopaque TotalPath toolsInspect
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.

Resources