Skip to main content
Glama
Sign In
Wicked MCP server

Wicked MCP server

by WickedAPI
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Hybrid

identity_get_nonce

Get a fresh single-use nonce and message to sign before registering or taking a real-wallet identity challenge; valid for 5 minutes.

Instructions

[Wicked Identity] Real-wallet path, step 1: a one-time nonce + message to sign. Every signed identity call needs a fresh nonce (single-use, 5-minute TTL). Not needed for sandbox identities.

Use when you are about to register or take a challenge and need a fresh one-time message to sign. Not for checking someone's status, which needs no signature.

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_nonce"
  }
}

Input Schema

NameRequiredDescriptionDefault
walletYesYour 0x wallet address on Base, or the sandbox wallet from identity_sandbox_register.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.2
    • 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."
  2. First observedv0.3.1

TDQS

A4.9/5.0
Behavior5/5

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

While annotations already show it is not read-only or idempotent, the description adds high-value behavioral context: the state is written upstream, it is single-use, and has a 5-minute TTL. This critical timing/state information is crucial for agent logic.

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?

The description is highly structured and avoids filler. While slightly verbose to include all contextual details, the information is front-loaded and clearly segmented, making it easy to parse for an AI.

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?

The definition is highly complete for a step-based flow tool, detailing its purpose, required input format (wallet context), and stateful, non-idempotent nature, which fully equips the agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema coverage is 100%, the description adds vital meaning by specifying that the input 'wallet' must be a '0x wallet address on Base' or a specific sandbox wallet ID. This guides the agent on the required format and environment context.

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 states the tool's purpose as a prerequisite for signing or taking a challenge ('a one-time nonce + message to sign'). It effectively differentiates itself from sibling tools like identity_status, which is used for checking status.

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?

It provides explicit instructions on when to use the tool (register or take a challenge) and when explicitly *not* to use it (checking status), leaving no ambiguity for the agent.

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