Skip to main content
Glama
Sign In
Wicked MCP server

Wicked MCP server

by WickedAPI
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Hybrid

identity_status

Read-onlyIdempotent

Check whether a wallet currently holds a valid, unexpired agent assertion without signatures. Use this read-only query to confirm status before relying on an agent's identity.

Instructions

[Wicked Identity] Does a wallet currently hold a valid, unexpired assertion? No signature needed. Pays via x402, or pass api_key (get one free from identity_get_test_key) / set IDENTITY_API_KEY. Sandbox wallets are never verified; they report sandbox: true and sandbox_verified instead.

Use when you want to know whether a wallet currently holds a valid, unexpired agent assertion. Not for becoming verified (start with identity_get_nonce).

Behavior: read-only.

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

Input Schema

NameRequiredDescriptionDefault
walletYesThe 0x wallet address.
api_keyNoOptional x-api-key, e.g. from identity_get_test_key.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.2
    • addedInput schema / properties / api_key
      Added value: +{
+  "description": "Optional x-api-key, e.g. from identity_get_test_key.",
+  "type": "string"
+}
  2. First observedv0.3.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say read-only/idempotent/open-world; the description adds materially new facts: no signature is required, the call is paid via x402 unless an api_key is supplied (with two acquisition paths), and sandbox wallets are never reported as verified. These are auth, cost, and result-semantics details an agent cannot get from annotations.

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 core question is front-loaded and the payment/auth caveat is compactly bundled into one sentence. A little density remains in the x402/api_key clause, but no sentence is wasted.

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?

With no output schema, the description still signals what the response looks like by naming the verified / sandbox / sandbox_verified fields, which is enough for an agent to interpret results. A brief note on non-verified failure modes (e.g. expired vs never-issued) is the only real omission.

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

Parameters3/5

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

Schema coverage is 100%, so both wallet and api_key are already documented in the schema. The description only restates the api_key sourcing hint and does not add format or validation semantics beyond that. Baseline 3 is appropriate when the schema carries the burden.

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?

Opens with a precise question form of a specific verb+resource: whether a wallet currently holds a valid, unexpired assertion. It is immediately distinguishable from identity_get_nonce and identity_register, which are named or implied as the verification path.

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?

Explicitly states the triggering condition ("Use when you want to know whether a wallet currently holds a valid, unexpired agent assertion") and an exclusion with a redirect ("Not for becoming verified (start with identity_get_nonce)"). That is the full when/when-not/alternative triad.

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