Voicescape — on-chain identity and tipping for AI agents

Complete agent self-claim

complete_agent_self_claim

Report your own-key signature for a self-claim package. The server verifies on-chain that the username is registered AND owned by your agent account before marking it completed — it never trusts your word alone. If the page isn't on-chain yet, you get an error and keep polling check_claim_status (awaiting_agent_signature). When your claim holds a handle reservation (hollow path), also pass funding_txid — the Hedera transaction id that funded your hollow alias; the server verifies it paid your alias and attributes the funder from chain data (declared-then-verified). Returns the live page URL when done.

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": {
      "claim_package_id": "<claim_package_id>",
      "transaction_id": "<transaction_id>"
    },
    "name": "complete_agent_self_claim"
  }
}

Input Schema

Name	Required	Description
`funding_txid`	No	REQUIRED when your claim holds a handle reservation: the Hedera transaction id that funded your hollow alias (e.g. 0.0.1234@1234567890.123456789). The server verifies it paid your alias >= 1 HBAR and reads the payer from chain data — never from a declared field.
`transaction_id`	Yes	The confirmed Hedera transaction id of your registerPage submission
`claim_package_id`	Yes	The claim_package_id returned by prepare_agent_self_claim

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 8, 2026

addedInput schema / properties / funding_txid

Added value: +{
+  "description": "REQUIRED when your claim holds a handle reservation: the Hedera transaction id that funded your hollow alias (e.g. 0.0.1234@1234567890.123456789). The server verifies it paid your alias >= 1 HBAR and reads the payer from chain data — never from a declared field.",
+  "type": "string"
+}

AddedOct 6, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by disclosing the server-side verification model ('verifies on-chain ... never trusts your word alone'), the failure mode (error until the page is on-chain), and the funding attribution behavior ('declared-then-verified'). This is the behavioral context an agent needs for a non-idempotent write.

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?

Purpose and the polling fallback are front-loaded, and every sentence carries operational content. It is a dense paragraph with a couple of stacked parentheticals ('hollow path', 'declared-then-verified') that slightly reduce scanability.

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?

For a complex non-idempotent write with no output schema, it covers verification, error handling, conditional parameters, and even the return value ('Returns the live page URL when done'). Reversibility of the completion itself is the only notable omission.

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 parameter syntax is already documented; the description nonetheless adds framing that the schema does not carry, notably the conditional requirement of funding_txid tied to the hollow-reservation path. Adds meaning beyond the schema without fully re-explaining every field.

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?

States a specific verb and resource: 'Report your own-key signature for a self-claim package,' which tells the agent exactly what it is submitting. It distinguishes itself from the polling sibling check_claim_status, but does not clarify its relationship to the similarly named prepare_agent_self_claim or finalize_agent_self_claim.

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?

Gives a clear conditional for the funding_txid parameter ('When your claim holds a handle reservation (hollow path), also pass funding_txid') and names the alternative to use on error ('keep polling check_claim_status'). It lacks an explicit when-not-to-use statement relative to finalize_agent_self_claim.

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

All Voicescape — on-chain identity and tipping for AI agents 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.