Skip to main content
Glama
Sign In
Wicked MCP server

Wicked MCP server

by WickedAPI
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Hybrid

identity_get_challenge

Requests a time-boxed liveness challenge for a registered wallet so agents can answer in one pass before expires_at.

Instructions

[Wicked Identity] Request a real time-boxed liveness challenge (constrained-generation task, 30s budget). The clock starts when this returns: answer in ONE pass via identity_submit_response before expires_at. Real wallet: needs a fresh signed nonce (fetch + sign the nonce for the NEXT call before calling this). Sandbox: just wallet + sandbox_token.

Use when your wallet is registered and you want the time-boxed agent-liveness challenge (about 12 seconds to answer). Not for registering first (use identity_register).

Behavior: writes state upstream (not read-only); needs the credentials or wallet signature noted above where applicable.

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": {
      "wallet": "<wallet>"
    },
    "name": "identity_get_challenge"
  }
}

Input Schema

NameRequiredDescriptionDefault
nonceNoReal wallet: nonce from a FRESH identity_get_nonce call. Omit for sandbox.
walletYesYour 0x wallet address on Base, or the sandbox wallet from identity_sandbox_register.
signatureNoReal wallet: 0x-prefixed ECDSA signature over that nonce's message. Omit for sandbox.
sandbox_tokenNoSandbox identity: the sandbox_token from identity_sandbox_register. Use INSTEAD of nonce/signature.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.7.2
    • changedInput schema / properties / nonce / description
      Previous value: -"Nonce from a FRESH identity_get_nonce call."New value: +"Real wallet: nonce from a FRESH identity_get_nonce call. Omit for sandbox."
    • addedInput schema / properties / sandbox_token
      Added value: +{
+  "description": "Sandbox identity: the sandbox_token from identity_sandbox_register. Use INSTEAD of nonce/signature.",
+  "type": "string"
+}
    • changedInput schema / properties / signature / description
      Previous value: -"0x-prefixed ECDSA signature over that nonce's message."New value: +"Real wallet: 0x-prefixed ECDSA signature over that nonce's message. Omit for sandbox."
    • changedInput schema / properties / wallet / description
      Previous value: -"Your agent's 0x wallet address on Base."New value: +"Your 0x wallet address on Base, or the sandbox wallet from identity_sandbox_register."
    • changedInput schema / required
      Previous value: -[
-  "wallet",
-  "nonce",
-  "signature"
-]New value: +[
+  "wallet"
+]
  2. First observedv0.3.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already flag readOnlyHint=false, idempotentHint=false, openWorldHint=true, and the description adds real value beyond that: the clock starts on return, the challenge is one-pass, and real-wallet vs sandbox credential requirements differ. Minor blemish: it says '30s budget' and then 'about 12 seconds to answer', which leaves the actual time constraint ambiguous. The trailing 'writes state upstream (not read-only)' largely restates the annotation.

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 action and the clock constraint, and the wallet/sandbox split is clearly separated. It loses a point for redundancy: the closing 'Behavior: writes state upstream (not read-only); needs the credentials or wallet signature noted above where applicable' repeats the annotation and the credential info already stated in the first paragraph.

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?

No output schema exists, and the description does step in by naming expires_at as a returned field and by describing the one-pass answer flow. Some return-shape detail (what the challenge itself looks like) is left implicit, but for a challenge-issuing tool the agent has enough to call it and to know what to do next.

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 genuine ordering semantics the schema cannot: for a real wallet you must fetch and sign the nonce for the next call BEFORE invoking this, and sandbox uses wallet + sandbox_token instead of nonce/signature. That cross-tool sequencing is the kind of meaning the schema descriptions only hint at.

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 ('Request a real time-boxed liveness challenge') and immediately characterizes the payload ('constrained-generation task'), so the agent knows what it is getting back in kind, not just name. It also names the sibling it is not (identity_register) and the follow-up (identity_submit_response), making it distinguishable without opening a 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?

Explicit preconditions ('wallet is registered', fresh nonce fetched and signed before the call) and an explicit exclusion ('Not for registering first (use identity_register)'). The answer path via identity_submit_response before expires_at is spelled out, so the agent knows the next tool and the deadline.

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

Deploy Server

Other Tools