DebitMyData Agentic Superhighway

Prove control of the controller key or wallet

dmd_prove_wallet_control

Two calls. Without challenge_id and signature: returns a one-time challenge for one controller. Sign its message with that controller, then call again with challenge_id and signature. A wrong signature uses up the challenge. With both a key and a wallet, prove each (registration status lists what is still to prove).

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": {
      "registration_intent_id": "<registration_intent_id>"
    },
    "name": "dmd_prove_wallet_control"
  }
}

Input Schema

Name	Required	Description
`signature`	No	Signature of the challenge message: Ed25519 (base64url) for a key, or the wallet's personal_sign / signMessage result (0x...) for a wallet
`challenge_id`	No	Leave empty to get a new challenge
`controller_type`	No	When getting a challenge: which controller to prove, ed25519 (the key) or eip155 (the wallet). By default the next one still to prove.
`registration_intent_id`	Yes	registration_intent_id from the quote (dmd_did_intent_...)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4/5.0

Behavior4/5

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

The description adds behavior not in the annotations or schema: the challenge is one-time, and 'A wrong signature uses up the challenge', which is a critical consequence an agent must know before invoking. Annotations only declare readOnly=false, destructive=false, openWorld=false, so this failure-mode disclosure is genuinely additive. It does not explain retry/error recovery beyond the used-up challenge.

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 tight sentences with no filler, and the ordering information (first call, then second) is front-loaded. The opening 'Two calls' is slightly abrupt and would read better fused with a purpose clause, but nothing is redundant.

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, return values need no explanation, and the description covers the two-phase flow, the signature-consumption risk, and the multi-controller case. What is missing is the post-success state (what proving control unlocks, e.g. registration completion) and any indication of challenge expiry.

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 cross-parameter meaning the schema cannot: that challenge_id and signature must be omitted together on the first call and supplied together on the second, and that controller_type selects which controller is being proven. This coupling is the main usage hazard and the description addresses it directly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The definition conveys a specific verb+resource (prove control of a controller key or wallet) through its two-step challenge/sign flow, and distinguishes itself from the status-checking sibling by pointing at 'registration status lists what is still to prove'. The purpose statement is embedded in protocol steps rather than stated in one clear sentence, so it leans on the title somewhat.

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?

It gives explicit sequencing: call without challenge_id/signature first, sign the `message`, then call again with both; and it states the rule for the dual-controller case ('With both a key and a wallet, prove each'). It references registration status as the source of what remains to prove, which effectively routes the agent, though it does not name or contrast a concrete alternative tool.

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

All DebitMyData Agentic Superhighway 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.