Skip to main content
Glama
Sign In

Rokha

by ai.rokha
OverviewDiscussionsAdmin

Finish wallet registration / login → JWT

auth_wallet_verify

Step 2: submit the signed challenge. On success returns session_token — a JWT to send as Authorization: Bearer <token> on every subsequent MCP/API request, unlocking the owner-scoped tools (page_claim, create_harness, rig_author, registry_publish, schedules, …). Solana: Ed25519 signature over the raw challenge message bytes (base58 or comma-separated bytes). EVM: EIP-191 personal_sign hex.

Input Schema

NameRequiredDescriptionDefault
signatureYesThe challenge message signed by the wallet's key: base58 for Solana, 0x hex for EVM.
challenge_idYesThe id auth_wallet_challenge returned.
wallet_addressYesThe same wallet address you passed to auth_wallet_challenge.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
  2. Changed3 schema fields changed
    • addedInput schema / properties / challenge_id / description
      Added value: +"The id auth_wallet_challenge returned."
    • addedInput schema / properties / signature / description
      Added value: +"The challenge message signed by the wallet's key: base58 for Solana, 0x hex for EVM."
    • addedInput schema / properties / wallet_address / description
      Added value: +"The same wallet address you passed to auth_wallet_challenge."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the call mints a JWT, exactly how to transmit it ('Authorization: Bearer <token>' on every subsequent request), and which capability set it unlocks. That is meaningful behavioral context for a state-changing auth handshake. Gaps remain around token lifetime/expiry and failure or re-submission behavior, which an agent would need to handle.

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?

Front-loaded with the step number and outcome, then chain-specific encoding detail, then the unlock list — a sensible ordering with little waste. The trailing tool enumeration with an ellipsis ('schedules, …') is slightly loose but still informative rather than filler.

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 three-parameter auth-completion tool with a full output schema, the description covers the prerequisite, the return value's use, the header format, and per-chain signature encoding. Since an output schema exists, it need not document response shape, and nothing an agent needs to invoke it correctly is missing.

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 would be 3, but the description adds real meaning beyond the schema: the signature must be Ed25519 over the raw challenge message bytes on Solana (base58 or comma-separated bytes) and EIP-191 personal_sign hex on EVM. That signing-standard detail is not derivable from the schema's simpler 'base58 for Solana, 0x hex for EVM' note.

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?

States a specific verb and resource ('submit the signed challenge') and frames itself explicitly as 'Step 2', which cleanly separates it from the sibling auth_wallet_challenge (step 1). The title plus the success outcome (returns session_token JWT) make the tool's identity unambiguous 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The prerequisite is explicit: this runs after auth_wallet_challenge, whose challenge_id is required. It also names the downstream owner-scoped tools that become available once the JWT is held, giving strong context for why and when to call it. It stops short of stating when-not to call it (e.g., if a valid token already exists), which keeps it from a 5.

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

All Rokha toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources