Nopaque TotalPath

Get a Link for a Human to Claim This Workspace

getClaimLink

Mint a one-time link that a human opens in a browser to take ownership of this workspace: they set an email and password, and can attach payment to buy more capacity. Give the link to the person. You never need to open it, and you cannot use it yourself.

USE WHEN:
- Free capacity is running low or exhausted (getWorkspaceUsage) and the person wants to keep going
- verifyAnchorCode returned freeGrantOutcome not-owed or refused
- The person wants to see the workspace, its call history or its keys in the TotalPath web app
- The person asks how to pay

WHAT YOU GET BACK (201):
- url: the link. Valid for ONE HOUR and usable ONCE. Pass it to the person as-is.
- expiresAt: when it stops working

AFTER THE PERSON CLAIMS:
Your API key keeps working exactly as before. The person now owns the workspace, can see everything you did, and can buy capacity that your key can then spend. Nothing you need to do.

WHEN IT IS REFUSED:
- 409 with reason workspace-claimed: a human already owns this workspace, so no more claim links can be issued. Tell the person to sign in at https://www.nopaque.co.uk instead.
- 503: the link could not be issued just now. Try again shortly.

A link that expires unused is harmless. Call this again for a fresh one.

RELATED TOOLS:
- getWorkspaceUsage: check the balance before deciding whether the person needs to pay
- verifyAnchorCode: must have succeeded before the workspace can do anything worth paying for

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "getClaimLink"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`url`	Yes	The token is in the fragment, after `#t=`.
`expiresAt`	Yes	One hour after minting.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say this is a non-read-only, non-idempotent, non-destructive local operation; the description adds far more: the link is single-use and valid one hour, the caller cannot or need not open it, the API key keeps working after the claim, and the failure modes (409 workspace-claimed, 503 retry) are enumerated with the remedial action. That is substantive behavior beyond what the annotations convey.

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 structure is strongly front-loaded and scannable, with the key fact (one-time, one-hour, hand to the person) in the first sentence and labeled sections after. It is somewhat long for a zero-argument tool, and the 'Give the link to the person / you never need to open it' and 'expires unused is harmless' lines repeat the single-use point already made in WHAT YOU GET BACK.

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 zero-parameter tool with an output schema, everything an agent needs is present: what to do with the link, the expiry and single-use constraints, success payload, and both documented error paths with the correct fallback (send the person to sign in at the web app). Nothing material is left to inference.

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?

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning left to add. The description correctly spends no words on inputs and instead documents the returned url/expiresAt, which is a reasonable substitution.

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 opens with a precise verb and artifact: 'Mint a one-time link that a human opens in a browser to take ownership of this workspace.' It goes on to state the exact consequence (email/password set, payment attached), which no sibling tool does, so the tool is unambiguous against getWorkspaceUsage, verifyAnchorCode and the other read-oriented siblings.

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?

An explicit USE WHEN block names the triggering conditions (capacity low/exhausted, verifyAnchorCode returned not-owed or refused, person wants the web app, person asks how to pay) and a RELATED TOOLS block explains the ordering dependency on verifyAnchorCode. This is the strongest form of when-to-use guidance: concrete conditions plus named prerequisites.

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.