Wicked MCP

identity_submit_response

Submit your answer to a Wicked Identity challenge. Scored honestly as pass / fail / inconclusive — never forced to a binary result. On pass, the response includes a short-lived signed assertion_token (a standard JWT) that anyone can verify against identity_jwks, and identity_status will report your wallet as verified until it expires.

Requires a real signature over identity_get_nonce's message — this tool
does not sign anything itself. Note this is a DIFFERENT nonce call than
the one used for identity_get_challenge; fetch a fresh one.

Args:
    wallet: Your agent's 0x wallet address on Base.
    nonce: The nonce from a fresh identity_get_nonce call.
    signature: The 0x-prefixed ECDSA signature over that nonce's message.
    challenge_id: The challenge_id from identity_get_challenge.
    response_text: Your answer, exactly as the challenge's instructions
        specify (e.g. raw lowercase words, no extra commentary).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`nonce`	Yes
`wallet`	Yes
`signature`	Yes
`challenge_id`	Yes
`response_text`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the tri-state outcome (pass/fail/inconclusive, never forced binary), the resulting state change (identity_status reports the wallet as verified until expiry), and the verifiability of the emitted JWT via identity_jwks. This is rich side-effect and return-path context beyond anything structured.

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 purpose, then behavior, then a clean Args block; nearly every sentence carries distinct value. It is somewhat long and the scoring-explanation sentence borders on editorializing, but nothing is wasted enough to drop below a 4.

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?

Even though an output schema exists (so return values needn't be described), the description still explains the key returned artifact (the JWT and how to verify it). Combined with the cross-tool prerequisites, an agent has everything needed to invoke this 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?

Schema description coverage is 0%, so the description must compensate, and it documents all five params: wallet (0x address on Base), nonce (from a fresh identity_get_nonce), signature (0x-prefixed ECDSA over the nonce message), challenge_id (from identity_get_challenge), and response_text (exact formatting per challenge instructions). This fully covers the schema gap.

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+resource ('Submit your answer to a Wicked Identity challenge') and immediately clarifies the scoring model and the pass-path side effect (signed assertion_token). It is clearly distinguishable from sibling identity_get_challenge / identity_get_nonce by naming them explicitly.

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?

Gives an explicit prerequisite (a real signature over identity_get_nonce's message; the tool does not sign) and routes the agent to the correct sibling: 'this is a DIFFERENT nonce call than the one used for identity_get_challenge; fetch a fresh one.' When-to-use and which alternative to pair with are unambiguous.

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

All Wicked 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.