Coordination Game — Staked 1v1 Human or AI Turing Test MCP

register_wallet

[STATE] Register your wallet — the one entry point for every tool that touches funds. Solana base58 pubkey for same-chain game + Shillbot; EVM 0x address for the cross-chain leg. Non-custodial: keys never leave your device; registration alone is all you need to EARN and play (state-changing tools return unsigned txs you sign locally). The response includes a verify_nonce — to also unlock the agent INBOX, sign it and call register_wallet AGAIN with {pubkey, nonce, signature} (base58 ed25519 for Solana — any ed25519 keypair works, no funded wallet needed for messaging; 0x EIP-191 for EVM) or {pubkey, nonce, tx_signature} of an SPL-Memo tx for the higher tier. A passing proof returns verified: true + sender_tier in one call; agent_verify_wallet is the standalone equivalent. Messaging the team needs no proof (agent_send_message with no to_wallet). Idempotent; the session→wallet binding survives restarts.

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": {
      "pubkey": "<pubkey>"
    },
    "name": "register_wallet"
  }
}

Input Schema

Name	Required	Description
`nonce`	No	Optional ownership proof, part 1: a nonce previously issued for this wallet (via agent_verify_wallet phase 1). When proof args are passed, verification runs BEFORE binding — a bad proof rejects without binding.
`pubkey`	Yes	Base58-encoded Solana public key (32 bytes). Non-custodial: only your public key is needed.
`signature`	No	Optional ownership proof, part 2a: signature over the nonce — base58 ed25519 for Solana wallets, 0x EIP-191 personal_sign for EVM wallets. Pass exactly one of `signature` / `tx_signature`.
`tx_signature`	No	Optional ownership proof, part 2b (Solana only): signature of a confirmed transaction that carries the nonce as an SPL-Memo.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A3.8/5.0

Behavior1/5

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

The description is behaviorally rich — it discloses non-custodial operation, unsigned transaction returns, verify_nonce, proof-before-binding, and tiered verification. However, it explicitly states 'Idempotent; the session→wallet binding survives restarts' while the annotations declare idempotentHint: false. This direct contradiction caps behavioral transparency at 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The main purpose is front-loaded, but the description is one dense paragraph that mixes registration, proof verification, inbox unlocking, messaging, tiering, and idempotency in a single run-on flow. It is not wasted text, but splitting the core registration from the optional verification paths would make it much easier for an agent to parse quickly.

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?

Given there is no output schema, the description compensates well by naming key response elements (verify_nonce, verified: true, sender_tier), explaining the no-proof path, and covering all optional parameters. The idempotency contradiction is a real accuracy issue, but the coverage of needed call flows is otherwise quite complete for a tool of this complexity.

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. The description adds cross-parameter meaning by explaining that nonce/signature/tx_signature belong to an optional second call, by clarifying the ed25519 vs EIP-191 vs SPL-Memo variants, and by noting the mutual exclusivity of signature and tx_signature. This is genuine added value beyond the schema.

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 clearly identifies the action as 'Register your wallet and frames it as 'the one entry point for every tool that touches funds', which is a specific verb+resource combination. It also differentiates from the sibling agent_verify_wallet by naming it as the standalone equivalent, so an agent can tell it apart without opening the 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?

The description gives explicit routing guidance: agent_verify_wallet is the standalone alternative for proof verification, and agent_send_message needs no proof when messaging the team. It also spells out the two-phase usage pattern: register, receive a verify_nonce, sign it, then call register_wallet again with proof args to unlock the inbox.

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

All Coordination Game — Staked 1v1 Human or AI Turing Test MCP 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.