Wicked MCP

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

With no annotations, the description carries the full burden and does well: it discloses the time-boxed nature, a default 12s budget, the expires_at deadline, that the task is constrained generation (exact word count + letter-sum), and critically that it does not sign anything itself and requires a real signature over the nonce message. Rate limits and failure modes are unstated, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then the crucial 'read the instructions carefully' caution and deadline, then args. The Args block is slightly verbose, but each sentence carries operative information, so nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating, multi-step, signature-gated tool, the description covers the whole lifecycle: prerequisite registration, nonce acquisition, signing responsibility, the challenge's constraints and deadline, and the downstream submission tool. Since an output schema exists, return values need no elaboration, and referenced fields (instructions, time_budget_seconds, expires_at) are enough to orient the agent.

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

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

Schema coverage is 0%, so the description must fully compensate, and it does: wallet is defined as the 0x Base address that must already be registered, nonce as coming from a fresh identity_get_nonce call, and signature as the 0x-prefixed ECDSA signature over that nonce's message. Every parameter gains meaning beyond the bare schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (request/obtain) plus resource (time-boxed agent-liveness challenge) with an explicit scope ('for an already-registered wallet'). It clearly positions itself against siblings: it needs identity_get_nonce output and feeds identity_submit_response, so an agent can place it in the flow 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.

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

Gives strong conditions and prerequisites: wallet must be registered via identity_register, nonce must come from a fresh identity_get_nonce call, and the answer must be submitted via identity_submit_response before expires_at. It names the downstream alternative tool but does not state explicit when-not-to-use or error/rejection conditions.

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

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

With no annotations, the description carries the full behavioral burden and does disclose key traits: the nonce is single-use with a short TTL and must not be reused across calls. It omits auth requirements and rate limits, but the critical nonce-lifetime semantics are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and sequencing are front-loaded in the first sentence, with the nonce-freshness caveat parenthetically attached where relevant. Efficient overall, though the args block restates the single parameter at some length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-annotation tool with an output schema, the description covers purpose, ordering in the flow, and nonce lifetime, so return values need no explanation. Minor gaps remain on auth/rate-limit behavior, but nothing blocks correct invocation.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it documents the single 'wallet' arg as 'your agent's 0x wallet address on Base', supplying format (0x) and chain (Base) context the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Get a one-time nonce + message to sign') and situates it in the Wicked Identity flow, making it clearly distinguishable from siblings like identity_register and identity_get_challenge. An agent knows exactly what this tool produces 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.

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

It explicitly positions the tool as 'the first step before identity_register, identity_get_challenge, or identity_submit_response' and warns each needs a fresh nonce. This gives clear when-to-use context and names the related tools, though it stops short of explicit when-not or alternative-selection guidance.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the access profile: 'Public, free, no key needed' tells the agent no auth is required. It also pins the algorithm (RS256) and the offline-verification model, though it says nothing about caching/rotation or freshness of the key set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with zero filler, and the core purpose is front-loaded before the usage guidance. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only key-retrieval tool with an output schema present, the description supplies everything needed: what it returns, the algorithm, the access profile, and the intended workflow. No return-value explanation is required since the output schema covers it.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; baseline for a parameterless tool is 4. Schema coverage is trivially 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get Wicked Identity's public JWKS (RS256 keys)') and clarifies the artifact's purpose — signature verification. It explicitly distinguishes itself from the sibling identity_status, so an agent can route correctly 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.

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

Gives an explicit use case ('verify an assertion_token's signature locally with a standard JWT library') and names the alternative it replaces ('independent of calling identity_status'). When-to-use and the alternative are both stated.

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

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

With no annotations, the description carries the burden and does well on the critical trait: it explicitly says the tool 'does not sign anything itself', so the agent must produce the signature externally, and it notes no stake is required. It omits failure modes, idempotency/duplicate-registration behavior, and any rate or auth constraints, so it is strong but not complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the operation and its key constraints before the Args list; the signing caveat is placed early where it matters. The Args block is slightly formulaic but every line carries usable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating registration tool with a full output schema, the description covers the prerequisite, the signing model, and the argument meanings. It lacks post-registration behavior (overwrite vs duplicate, error handling), which keeps it from being fully complete.

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

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 does: wallet is specified as a 0x address on Base, nonce must be fresh from identity_get_nonce, and signature is a 0x-prefixed ECDSA signature over that nonce's message. Each parameter gains semantics the bare schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (register your wallet with Wicked Identity) and immediately distinguishes it from related siblings by naming the dependency identity_get_nonce and the trait 'no stake required'. An agent knows exactly what this does 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.

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

Gives a clear precondition chain: the nonce must come from a 'fresh identity_get_nonce call' and the signature must cover that exact returned message. It does not state explicit when-not conditions (e.g. what to do if already registered), so it falls short of full alternative routing.

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

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

With no annotations, the description carries the full burden and does well: read-only, no signature required, callable unauthenticated via x402 with payment instructions in the 402 body, or via a free-tier IDENTITY_API_KEY. It stops short of stating rate limits, failure modes, or cost specifics beyond the 402 mechanism.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then the auth/payment model, then the arg, with no filler. The parenthetical about x402 payment instructions is the one slightly heavy clause but it is genuinely informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained; the description covers purpose, the two access paths, and the lone parameter. What remains unstated — error behavior on an expired or missing assertion — is minor for a simple read check.

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

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

Schema coverage is 0% and the single property is documented only as 'string', so the description must compensate. It does so by specifying the expected format ('The 0x wallet address to check'), which is real added meaning for an agent constructing the call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('check whether a wallet holds a valid, unexpired Wicked Identity assertion') and immediately scopes it as the read-only, third-party variant, which separates it from the write-side siblings like identity_register and identity_submit_response without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It says this is the check any third party can run on someone else's wallet with no signature, which tells the agent when this read path applies versus the challenge/nonce flow. It does not explicitly name identity_get_challenge or identity_get_nonce as the alternatives, so the routing guidance is clear but not exhaustive.

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

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the full behavioral burden and does so: it discloses irreversibility ('content is not recoverable'), the residual artifact ('only an audit row (no content) is kept'), the destructive blast radius of the default scope, and the single-use nature of the nonce. These are exactly the consequences an agent must weigh before invoking a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The irreversibility warning is front-loaded in the first clause, scope semantics follow, the prerequisite is stated before the argument list, and the Args block is terse with no filler. Every sentence carries operational weight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is unnecessary, and the description fills the remaining gaps for a high-risk mutation: signing flow, prerequisite call, scope defaults, side effects, and audit behavior. Nothing an agent needs to call this correctly is missing.

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

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 seven parameters, including provenance (timestamp and nonce come from memory_prepare), the single-use constraint on the nonce, the enum-like scope values with default, and a concrete limit on reason (max 200 chars). This adds meaning the bare schema cannot supply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('PERMANENTLY delete a memory') and immediately qualifies the operation type (hard delete / right-to-be-forgotten). It also distinguishes the two destruction modes ('chain' removes EVERY version vs 'version' removes only this row), which an agent needs to separate this from siblings like memory_deletions or memory_update.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It states a clear precondition ('Call memory_prepare with operation "delete" and the same arguments first') and explains which scope value to pick for which intent. It does not, however, name the adjacent alternatives an agent might reach for (e.g., memory_update to amend instead of destroy, or memory_deletions to inspect past deletions), so routing guidance stops short of explicit when-not-to-use.

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

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

No annotations are provided, so the description bears the behavioral burden. It usefully discloses that the log returns ids, times, and reasons but never content, and that a prepare step is required. It does not state authentication requirements beyond the signature fields, rate limits, or whether results are paginated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the tool's purpose and the prepare prerequisite, then lists args compactly. The four argument lines are brief and earn their place, though a little more format detail could be useful without bloating.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 required parameters, 0% schema description coverage, and an output schema that documents returns, the description covers the essential prepare flow and audit-log contents. It omits error behavior, retry semantics, and how to handle an expired nonce or timestamp, which are relevant for a security-sensitive signed call.

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

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. It explains that wallet is the agent's 0x wallet address, and that timestamp, nonce, and signature come from memory_prepare. It does not clarify formats, single-use enforcement beyond nonce, or signature message scope, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it is a deletion audit log returning ids, times, and reasons but never content. This distinguishes it from siblings like memory_history and memory_delete. The scope is clear, though it does not explicitly name which sibling to prefer for related queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly instructs the agent to call memory_prepare with operation "deletions" first, which is a concrete usage prerequisite. It does not, however, describe when to use this log versus memory_history or memory_search, so alternatives are not exhausted.

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

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

With no annotations, the description carries the full burden. It discloses important behavior: another wallet's id or a deleted one returns the same 404 as a nonexistent id, which is security-relevant. It also states nonce is single use and the signature is over memory_prepare's message_to_sign. It doesn't mention rate limits or other side effects, but covers key behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and important caveats, then lists args efficiently. It is appropriately sized for a tool with authentication and prerequisites. The formatting with 'Args:' is clean, though slightly less concise than possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 5-parameter authenticated tool with no annotations and an output schema (which handles return values), the description covers purpose, prerequisites, parameter meanings, and critical behavioral notes (404 uniformity, nonce use). It is nearly complete, missing only alternative usage guidance.

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

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. It documents all five parameters with meaningful context: wallet is the agent's 0x wallet address, memory_id is a UUID, timestamp and nonce come from memory_prepare (nonce single use), and signature is over memory_prepare's message_to_sign. This is strong param semantics despite no schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Fetch one of your memories by id.' It clearly distinguishes the operation from siblings like memory_search or memory_store, and the 404 behavior clarifies the access model. It doesn't explicitly contrast with memory_search or memory_history, but the operation is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives a clear prerequisite: call memory_prepare with operation 'get' and params {'memory_id': ...} first. This tells the agent when and how to use the tool. However, it doesn't say when to choose this over memory_search or memory_history for retrieving memory data.

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

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

With no annotations, the description carries the full burden and largely meets it: it discloses the read-only nature (history/chain), the wallet-signature auth flow, the prerequisite prepare step, and that the nonce is single-use. It does not spell out permissions or error behavior, so a 4 rather than 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and output shape, then lists args compactly. Every line earns its place; the arg list is slightly structural rather than prose, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still hints at them. Combined with the fully documented auth flow and prerequisite, an agent has everything needed to call this correctly.

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

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

Schema coverage is 0%, so the description must compensate, and it does: all five required params are documented, including their provenance (timestamp and nonce from memory_prepare; signature over message_to_sign; memory_id is any version's UUID). This fully fills the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific operation on a specific resource: return the full version chain for a memory, ordered oldest first. It even names the returned fields (valid_from / valid_until / superseded_by), so an agent can distinguish this from memory_get (single version) 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.

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

"Works from any version's id" and "Call memory_prepare with operation 'history' first" give clear prerequisite and context guidance. It stops short of naming alternatives or when-not-to-use conditions, so it doesn't reach the top band.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses that the server never signs or holds a key, that each call requires a fresh signature, and that nonces are single-use with a 5-minute expiry. These are exactly the behavioral traits an agent needs to avoid a failed or rejected call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then the signing workflow, then a structured Args section — each part earns its place. It is somewhat long, but the length is justified by the multi-step protocol and the parameter documentation gap it must fill.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. Given the multi-step signing flow and the 0% schema coverage, the description supplies everything required: the exact signing algorithm, the required follow-up call, the carried-over arguments, and the freshness constraints.

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

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 does: it enumerates all seven valid `operation` values, explains that `wallet` scopes memories, and gives concrete per-operation `params` examples (content/tags for store, q for search, memory_id for get/update/history/delete). This fully documents all three parameters beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource: 'get the exact message to sign,' and frames it as 'Step 1 of every Wicked Memory call.' This clearly distinguishes it from siblings like memory_store or memory_search, which are the actual operations that follow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly prescribes the workflow: sign `message_to_sign` with EIP-191 personal_sign, then call the matching tool with the SAME arguments plus timestamp, nonce, and signature. It also states the operative constraints (5-minute timestamp window, single-use nonce, must prepare again for every call), leaving nothing to inference.

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

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 strict wallet scoping, metered-endpoint behavior, free-tier vs. the 402/x402 flow with price and chain, and the non-obvious fact that a 402 does not consume the nonce. Default version-filtering behavior (active-only) is also stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and wallet scoping are front-loaded, with access/payment and version-selection details following in logical order. The payment paragraph is somewhat verbose, but every clause (price, chain, resend-same-args rule) is operationally necessary, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, no-annotation tool with a bare schema, it covers auth flow, payment/quota behavior, scoping guarantees, and version semantics, and an output schema already exists so return-shape detail is unnecessary. Nothing material 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.

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

Schema coverage is 0%, so the description must compensate, and it documents every one of the 12 parameters with meaning beyond the bare schema: limit range and default (1-50, default 10), tags as AND-semantics, ISO-8601 bounds for created_after/before, as_of as a point-in-time version selector, single-use nonce, and the relationship of signature to memory_prepare's message_to_sign.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource ('Semantic search over YOUR memories') and immediately bounds scope: results are limited to the given `wallet`. It also specifies the ranking mechanism (real cosine similarity at query time, returned as `score`), which cleanly distinguishes it from memory_get and memory_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a hard prerequisite ('Call memory_prepare with operation "search" and these same arguments first') and an explicit retry path on payment failure with identical arguments. It also tells the agent how to widen retrieval (as_of vs. include_superseded). It does not explicitly contrast against sibling retrievers like memory_get, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the free/fair-use rate limit, the mandatory two-step prepare-and-sign flow, that a real embedding is computed at write time, and that the stored memory is returned. It omits behavior around overwrites/conflicts and whether content is deduplicated, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the critical two-step flow before the args list, and nearly every sentence earns its place. Minor waste in the trailing "validity window, ..." ellipsis, which is imprecise in a return-value description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description need not detail returns, and it correctly focuses on the workflow, the signing prerequisite, limits, and parameter meanings. 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.

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

Schema description coverage is 0%, yet the description documents every one of the 8 parameters with meaningful semantics: wallet scopes the memory, content max 16 KB, nonce is single-use, timestamp/nonce/signature come from memory_prepare, tags up to 20, metadata max 8 KB free-form. This fully compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Store a memory in Wicked Memory") and is clearly distinguishable from siblings like memory_prepare, memory_update, and memory_get. An agent knows exactly what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives explicit prerequisite guidance: call memory_prepare with operation "store" and the same arguments, sign the message, then pass timestamp/nonce/signature here. This is strong when-to-use context. It stops short of routing between this and alternatives like memory_update, but the write-path workflow is unambiguous.

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

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 richly: versioning/history retention, carry-over of omitted fields, single-use nonce, signature requirement, content re-embedding, and the 409 failure mode that names the current id. This is exactly the behavioral context the annotations would otherwise provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The behavioral summary is front-loaded ahead of the args list, and every sentence carries information. It is slightly verbose in restating parameter purposes, but the structure (behavior first, args after) is well organized with little waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a signed, 9-parameter mutation tool with a 409 failure mode, the description covers the full call sequence, signing prerequisites, partial-update semantics, and even the return shape ('previous' and 'current'), which the output schema also supports. 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.

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

Schema description coverage is 0%, and the description compensates by documenting all 9 args, including the crucial distinction that memory_id must be the CURRENT version and that timestamp/nonce/signature come from memory_prepare. It also states the 'at least one of content/tags/metadata/source' rule. Minor gap: 'replacement' semantics for tags/metadata could note merge vs overwrite, but coverage is strong.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource and immediately clarifies the semantics that distinguish it: 'creates a new version and closes the old one.' An agent can tell this apart from memory_store and memory_delete from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly mandates the prerequisite workflow ('Call memory_prepare with operation "update" and the same arguments first') and states the key constraint ('Only the current version can be updated (409 otherwise, naming the current id)'). This is when-to-use plus when-it-will-fail guidance.

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

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

With no annotations, the description carries the full burden, and it delivers real behavioral context: the registry is public, free, and requires no key or payment, which is exactly the access information an agent needs before calling. It stops short of disclosing result count, ordering, or pagination behavior, so it is not fully complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with what the tool returns and followed by the routing hint. Every clause earns its place and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers purpose, access model, and the alternative tool. Only minor gaps remain — how many tools are returned and how 'top scored' is ordered.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument call and adds no misleading parameter expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get Wicked Registry's top scored active tools') and pins down the scope with 'top scored' and 'active', which distinguishes it from the sibling registry_search_tools. An agent can tell what it returns 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.

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

Explicitly names the alternative ('before calling registry_search_tools with a specific filter') and the condition that makes this tool preferable — use it for a quick unfiltered look first. No inference required.

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

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

With no annotations, the description carries full behavioral burden and delivers: it does NOT sign on your behalf, unsigned/client-asserted wallets are rejected, the endpoint is polled on an interval, the timestamp must be within 10 minutes, and schema_url toggles a score component. This is rich, non-obvious operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then the signing prerequisite, then Args. Every line earns its place, though the verbatim signature-message block and repeated 0x/format notes add some bulk that could be marginally tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-param, 8-required mutation tool with no annotations but an output schema, the description covers purpose, auth/signature flow, timing constraints, and all parameter meanings. Return values are covered by the output schema, so nothing essential is missing.

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

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 does—every one of the 9 params is explained, including the exact signed-message template, protocol enum values ("x402", "mcp", "rest"), timestamp window, and that schema_url is optional with a specific effect.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource ("Register a tool... with Wicked Registry") plus the concrete benefit ("real synthetic checks and a live reliability score"). It is clearly distinguishable from sibling registry tools like registry_search_tools, registry_report_tool, and registry_tool_detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

States clear context (you must own the tool, and you must produce a valid signature first) and gives the rejection condition for missing signatures. It does not explicitly name alternative siblings or when-not-to-use, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden, and it discharges most of it: it discloses the rate limit, no-auth access, manual review, and the key side-effect boundary (reports do not auto-suspend the tool). It omits specifics like the rate-limit value or how duplicate reports are handled, but the safety and workflow profile is unusually well surfaced for an unannotated mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then access constraints, then the side-effect caveat, then an Args block. Every sentence carries information an agent needs; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a report-filing tool with no annotations and 0% schema coverage, the description covers purpose, access, side effects, and every parameter. An output schema exists, so return values need not be explained, leaving nothing material missing.

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

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

Schema description coverage is 0% and the schema declares no enums, yet the description documents all four parameters and supplies the enum-like value set for 'reason' (downtime, incorrect_response, scam_or_abuse, schema_violation, other) that the schema lacks. This compensates fully for the coverage gap and adds meaning beyond the raw types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and object ('File a real complaint about a tool's reliability or behavior') plus the destination ('with Wicked Registry'). This is distinct from siblings like registry_tool_detail, registry_register_tool, and reputation_statement, so an agent can route to it 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.

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

Gives clear operating context ('Public, rate-limited, no auth required') and sets expectations ('Reviewed manually by an admin — filing a report does not auto-suspend the tool'). It does not name an alternative tool or state when-not to file, so it stops short of a full when/when-not routing statement.

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

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

With no annotations, the description carries the behavioral burden and does so well: it discloses the two auth modes (402 payment instructions in body, or REGISTRY_API_KEY), and notably explains that min_score excludes tools with no check history rather than treating them as 0. It does not cover rate limits or destructive potential, but this is a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and auth, then uses a clean Args list. Slightly verbose in places (the parenthetical about fabrication and payment instructions), but each line carries information and nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given five optional params and an existing output schema (so return values need not be described), the definition is nearly complete. It covers auth, filtering, sorting, and limiting; the only mild gap is lack of explicit sibling differentiation.

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

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 does: it documents every parameter with meaning, including concrete category and protocol examples, the actual protocol enum values (x402/mcp/rest), sort values, the limit range (1-200), and the non-obvious min_score exclusion semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (search Wicked Registry for x402/MCP tools) and clarifies the differentiator (real, live reliability data, never fabricated). It is clear, though it does not explicitly name how it differs from siblings like registry_featured_tools or registry_tool_detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage context is implied rather than stated: the auth paths (unauthenticated via x402 vs free-tier key) suggest when the tool works, but there is no explicit when-to-use or when-not-to-use guidance relative to the registry sibling tools.

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

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

With no annotations, the description carries the disclosure burden but only partially meets it: it clarifies access (public, free, no key/payment), which is genuinely useful behavioral context. It does not describe rate limits, caching, or what the badge output contains, relying on the output schema for return-shape details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, with the core action stated first and the access caveat second. The 'Args:' block is somewhat boilerplate but harmless. Nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-param read tool with an output schema present, the description covers purpose and access needs adequately. Return values are handled by the output schema, so the absence of output description is acceptable; only the identifier format is under-explained.

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

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

Schema description coverage is 0% and the only arg is 'tool_id'. The description does add a hint ('The tool's Wicked Registry id'), which slightly clarifies that this is a registry identifier rather than an arbitrary one, but it provides no format example or sourcing guidance. Minimal but non-zero compensation for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Get a tool's current composite reliability score.' This is a clear, single-purpose read operation. It does not explicitly distinguish itself from siblings like registry_tool_detail or reputation_query, but the composite-score framing is distinctive enough to infer separation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The 'Public, free, no key or payment required' clause implies this is an open read anyone can call, which is useful context. However, it gives no explicit guidance on when to prefer this over registry_tool_detail or the reputation_* tools, leaving the choice to inference.

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

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

With no annotations, the description carries the burden and does well: it discloses two authentication paths (x402 payment flow or free-tier key) that an agent must resolve before calling. It does not cover rate limits, pricing details of x402, or error behavior, leaving some gaps for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, auth behavior second, parameter provenance third. Sized appropriately for a one-parameter tool with a small amount of prose padding around the Args block.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return contents needn't be spelled out; the description still names the main components returned. Auth, parameter source, and resource scope are all covered, leaving only minor operational details (rate limits, failure modes) unstated.

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

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

The schema's 0% coverage means the description must supply meaning, and it does: tool_id is defined as the Wicked Registry id and its provenance is given (registry_search_tools / registry_featured_tools). That is exactly the context needed to supply a valid value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('one tool's full score breakdown, component history, and recent real health checks from Wicked Registry'), and it distinguishes the tool from the sibling registry_search_tools and registry_featured_tools by scoping it to a single tool id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It tells the agent where tool_id comes from (registry_search_tools or registry_featured_tools) and how the call authenticates (x402 unauthenticated vs REGISTRY_API_KEY free tier). It does not explicitly say when to prefer this over registry_tool_badge or other registry siblings, but the single-tool detail use case is clear.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses the safety profile (parameterized, no injection surface), default sort direction, limit bounds of 1-200, and default limit of 20. It never states read-only semantics or permission requirements explicitly, and the return shape is left to the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose sentence followed by a clean Args block; each line earns its place. Slightly verbose but nothing is wasted, and the ordering is logical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-param tool with zero schema coverage and an existing output schema, the description covers all inputs thoroughly. The only gap is that it does not clarify how multiple filters combine (AND vs OR) or confirm the read-only nature, but nothing essential for a correct call is missing.

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

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

With 0% schema description coverage, the description fully compensates: it documents every one of the 8 params including example tier values, USDC units for stake bounds, the +/- prefix convention for sort direction with the four allowed fields, and the limit range and default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair (search/rank) and resource (registered agents) plus the dimensions queried (tier, stake, reputation, slash history), so an agent knows exactly what this returns. It does not explicitly distinguish itself from the four reputation_* siblings, which is the only thing keeping it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied by the filter list, but there is no explicit when-to-use versus reputation_statement, reputation_status, reputation_tiers, or reputation_transparency. The 'safe alternative to raw SQL' framing contrasts with a non-existent tool rather than routing the agent among real siblings.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses data scope (what events are and aren't included) and defers detail to a response 'note' field, but it says nothing about permissions, freshness, or mutability, and the return shape is only referenced rather than characterized.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core capability and the key exclusion in the first two sentences; the trailing 'Args' block is slightly redundant in formatting but carries real information. Minimal waste overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description supplies scope, exclusions, and parameter meaning. What remains missing is any routing against the several sibling reputation tools, but for correct invocation the definition is essentially sufficient.

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

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

Schema description coverage is 0% and the sole parameter has no schema-level title/description beyond its name, so the description must compensate. It does: 'The agent's 0x wallet address on Base' supplies both the expected format (0x address) and the required chain (Base), which the schema omits entirely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get an agent's full position + real event ledger') and enumerates the ledger contents (stakes, unstakes, withdrawals, slashes), which pins down the scope precisely. It does not explicitly name or contrast with the sibling reputation_* tools, so it falls short of the sibling-differentiation bar for a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied by the scope statement, and the exclusion of 'WickedAPI call volume or fees paid' nudges the agent away from this tool for those needs. However, with siblings like reputation_query, reputation_status and reputation_transparency present, there is no explicit guidance on when to pick this one over them.

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

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

With no annotations, the description carries the full burden and does disclose a real behavioral edge case: unregistered wallets return 404 and should be treated as 'unranked'. It also effectively characterizes the operation as a read. It stops short of stating auth/permission requirements or any rate-limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the operation and its return payload, followed by the important 404 caveat and then the argument. Three compact blocks, no filler. The repeated 'Args:' listing is slightly redundant but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so enumerating return fields is optional extra context rather than required. For an unannotated read tool the missing pieces are permission/auth prerequisites and how it differs from the other reputation_* tools; the critical unregistered-wallet case is covered.

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

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

Schema coverage is 0%, so the description must compensate, and it does: the single 'wallet' parameter is expanded beyond the schema's bare string to 'The agent's 0x wallet address on Base', giving both format and chain. It adds no detail about address validation or alternative accepted formats, but the gap is minor for a one-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Get an agent's current reputation') and enumerates the returned fields (tier, stake, score, slash count, badge), so the purpose is unambiguous. However, it never distinguishes itself from the closely named siblings reputation_query, reputation_statement, and reputation_transparency, leaving the agent to guess which reputation tool to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

There is no explicit when-to-use/when-not guidance and no mention of the sibling reputation tools as alternatives, so selection guidance is only implied by the tool name. It does add one genuine usage rule — interpret http_status 404 as tier 'unranked' rather than a failure — which prevents a common misuse.

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

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

No annotations are provided, so the description carries full burden, and it delivers real behavioral context beyond the schema: the values are live and admin-configurable, so callers must fetch them rather than cache assumptions. It omits auth/permission requirements and rate-limit behavior for the caller, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and followed by the key usage constraint, with the enumerated return fields in a compact parenthetical. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no further explanation, and the description already names the key fields anyway. Purpose plus the live/configurable behavioral note is everything an agent needs to call this zero-param getter correctly.

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

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

The tool takes zero parameters, so the schema-side baseline is 4. The description lists the returned fields rather than parameter semantics, which is appropriate and adds no confusion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) and resource (Wicked Reputation's live tier thresholds and benefits) and enumerates exactly what is returned. An agent can distinguish this from siblings like reputation_query or reputation_status without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The clause 'Read at call time rather than assumed' gives clear guidance on when to invoke it: whenever current thresholds matter, because they are admin-configurable. It stops short of naming alternative siblings or explicit exclusions, but the usage directive is unambiguous.

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

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

No annotations are provided, so the description carries the full behavioral burden. The verb 'Get' and the phrase 'live transparency numbers' imply a safe, non-mutating read, and the enumerated fields set expectations about the response. However, it says nothing about authentication requirements, caching/staleness of 'live' data, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with the core purpose front-loaded and the returned fields listed compactly after the colon. No filler, though the long field enumeration borders on restating the output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, yet it spends most of its length doing exactly that. It omits the one thing the schema cannot supply: when this tool should be chosen over its reputation_* siblings. Adequate but with a clear gap.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The enumerated field list is about return content rather than inputs, so it does not add parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('Wicked Reputation's live transparency numbers') and enumerates the exact fields returned, so the agent knows this is a read-only transparency/reporting endpoint. It does not, however, distinguish itself from siblings like reputation_status or reputation_query, so the agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives no indication of when to call this versus reputation_status, reputation_query, reputation_statement, or reputation_tiers. There are no prerequisites, exclusions, or alternative routing, so the agent is left to guess among four similarly named reputation tools.

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

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 thoroughly: it discloses that verdicts come from real-time HHEM inference (never cached), the exact rate limits (20/min, 30 open-mode/day), 429/Retry-After handling, and the 402 x402 payment path. It also clarifies the subtle semantics of confidence_score and the four verdict values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and uses clear labeled sections (Two modes, Reading the result, Access, Args) so it is scannable despite its length. It is on the long side, but almost every line carries non-obvious operational value, so waste is minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-mode verification tool, the description covers mode selection, verdict interpretation, evidence output, and failure/rate-limit handling, which is more than sufficient given an output schema already exists. An agent has everything needed to call it correctly and interpret results.

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

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

Schema coverage is 0%, so the description must compensate, and it does: claim is capped at 5,000 characters, context accepts a string or list and is REQUIRED for grounded mode but ignored in open mode, and mode defaults to grounded. This fully documents behavior the schema leaves bare.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (verify) and resource (a claim) with clear scope ('before you act on it or hand it downstream'). The args section distinguishes it from the sibling sanity_check_batch by emphasizing 'The single statement to verify'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly defines the two modes and their selection condition (grounded = faithful to supplied context, context REQUIRED; open = live web evidence, context ignored). Adds a 'suggested policy' telling the agent exactly how to act on each verdict, leaving nothing to inference.

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

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 richly: one payment/rate-limit hit covers the batch, the shared key budget (~20 req/min, 30 open-mode checks/day across all users), that grounded mode is exempt from the daily cap, http_status 429 with Retry-After and remediation paths, and 402 with x402 payment instructions when no key is configured. This is far beyond a generic 'batch verification' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the sibling contrast, then organized into a Returns paragraph, an Access/error-handling paragraph, and an Args block. The length is justified by the genuine operational complexity (batching, dual modes, rate limits, payment fallback); no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers everything an agent needs: ordering guarantee of the returned list, the fact that each result mirrors sanity_check's shape, mode-dependent behavior, batching constraints, and both 429 and 402 failure paths. An output schema exists, so the description appropriately points to sanity_check for field semantics rather than duplicating them.

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

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

Schema coverage is 0%, so the description must compensate, and it does: claims are 1-50 statements each up to 5,000 characters, context is a shared source that accepts a string or list of strings and is required for grounded mode, and mode's two valid values are spelled out with their semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Verify several claims in one call') and explicitly contrasts itself with its sibling: use this instead of calling sanity_check once per sentence. An agent can distinguish the batch variant from the single-claim variant without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives an explicit when-to-use trigger (multi-sentence output), the alternative it replaces (per-sentence sanity_check), and when each mode applies ('grounded' checks against context, 'open' checks live web evidence). It even warns that open mode is slow because a separate live search runs per claim.

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

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

No annotations are provided, so the description must carry the behavioral burden. It doesn't state authentication requirements, rate limits, whether the data is real-time or delayed, or any other operational characteristics. The only behavioral hint is the symbol mapping to Binance/Bybit, which is helpful but insufficient for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the core purpose. The Args section is concise and directly explains the parameter. There is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, one parameter, and a present output schema, the description covers the basic purpose and parameter semantics. However, it lacks usage context, behavioral details like data freshness or rate limits, and doesn't explain how the output is structured (though an output schema exists, so that's less critical). It's minimally adequate but has clear gaps.

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

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. It does explain that the symbol is a base crypto symbol and that it's mapped to <SYMBOL>USDT perpetual on Binance/Bybit, which adds meaningful context about the parameter's expected format and behavior. However, it doesn't cover edge cases like case sensitivity or whether other exchanges are supported. Baseline for 1 param with 0% coverage would be lower, but the added mapping detail earns a 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: retrieves funding rate and open interest for perpetual futures on a given crypto symbol. This is clear and identifiable, but the description does not distinguish this tool from siblings like wickedapi_price or wickedapi_momentum, so it's not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

There is no guidance on when to use this tool versus alternatives. The description doesn't mention when to prefer it over wickedapi_price or wickedapi_momentum, nor any conditions or exclusions. This is a clear gap.

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

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

With no annotations, the description carries the full behavioral burden. It implies a read-only fetch via 'Get' and discloses the supported symbol universe, but says nothing about auth requirements, rate limits, data freshness, or how the momentum score is scaled or interpreted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose sentence is front-loaded and the argument list is tight with no filler. The docstring-style 'Args:' formatting is slightly heavier than needed for two parameters but does not obscure the content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be described, and both parameters are fully enumerated. The only real gap is the absence of any explanation of what the momentum score represents or when to prefer it, which matters less for a simple read-only lookup.

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

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

Schema coverage is 0%, and the description compensates well by enumerating every valid symbol value and every valid timeframe value, plus the 1h default. It still doesn't explain what a timeframe selection means semantically or what units the score is expressed in, but the enumerated domains are the critical missing piece from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: "Get WickedAPI's momentum score for a symbol," which is unambiguous about what the tool returns. However, it never distinguishes itself from close siblings like wickedapi_price or wickedapi_funding_oi, so the agent must infer the boundary from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description lists valid inputs but gives no when-to-use guidance, no exclusions, and no mention of when an agent should pick momentum over the sibling price or funding/OI tools. Usage is only implied by the verb 'Get.'

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

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

With no annotations at all, the description carries the full behavioral burden, and it discloses very little: nothing about authentication, rate limits, whether 'current' means real-time or delayed, or what happens for an unknown symbol. The only behavioral detail is the conditional requirement on asset_class.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in the first sentence, and the argument notes are compact. The docstring-style 'Args:' block is slightly formal for a two-parameter tool but wastes little space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and both parameters are covered. For a simple lookup this is close to adequate, but the absence of any note on data freshness, error handling, or symbol coverage leaves gaps an agent may hit in practice.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it gives concrete examples for symbol (BTC, ETH, SUI, NVDA, SPY) and supplies the allowed values 'stock'/'crypto' for asset_class, which the schema lacks as an enum. It still doesn't state the exact curated-symbol list that determines when asset_class is mandatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the current price for a symbol') and names the source (WickedAPI), covering both crypto and stock. It is distinguishable from siblings like wickedapi_funding_oi and wickedapi_momentum by scope, though the description never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The asset_class field carries an implicit usage rule ('required for symbols outside the curated list, optional otherwise'), which is genuinely helpful context. However, there is no guidance on when to prefer this tool over sibling market-data tools such as wickedapi_momentum or wickedapi_funding_oi.

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