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 delivers strong behavioral detail: a 30s budget, the clock starting on return, a one-pass answer constraint, and a required fresh nonce. It omits failure/timeout semantics and what the challenge payload contains, keeping it just short of full transparency.

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?

Three dense sentences with the core action and deadline constraint front-loaded, followed by the real-wallet and sandbox invocation notes. Every sentence earns its place, though the parenthetical density slightly strains readability.

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 challenge-issuing tool with no output schema and no annotations, the description supplies the timing contract, the required workflow, and the auth-mode branching. It is nearly complete, only missing detail on the returned challenge structure and timeout/failure behavior.

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 100%, so the baseline is 3, but the description adds ordering meaning beyond the schema by specifying the nonce must be signed for the NEXT call and that sandbox uses wallet + sandbox_token instead of nonce/signature. This contextualizes the mutually-exclusive parameter sets rather than merely restating field docs.

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: 'Request a real time-boxed liveness challenge (constrained-generation task, 30s budget)'. It clearly delineates this from identity_get_nonce (prerequisite) and identity_submit_response (follow-up), so an agent can position it in the workflow without opening schemas.

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 states the follow-up path ('answer in ONE pass via identity_submit_response before expires_at') and names the prerequisite ('fetch + sign the nonce for the NEXT call before calling this'). It also routes between the real-wallet and sandbox invocation modes, giving when-to-use context and alternatives.

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. It discloses single-use behavior, a 5-minute TTL, and the real-wallet vs sandbox distinction. It stops short of describing response shape, error behavior, or any auth/permission requirements beyond the nonce flow.

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 front-load the action and then add the critical constraints (single-use, TTL, sandbox exception). Every phrase 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 simple one-parameter tool with no annotations or output schema, the description is nearly complete: it explains the nonce/message purpose, TTL, single-use nature, and sandbox exclusion. It could still specify the response format more explicitly, but an agent has enough to call it 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 100%, so the wallet parameter is already documented. The description adds useful context by framing the tool as the real-wallet path and saying it is not needed for sandbox identities, but it does not add syntax or validation detail beyond 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?

The description states a specific action ('a one-time nonce + message to sign') and places it in context ('Real-wallet path, step 1'). It also distinguishes the tool from sandbox identity flows with 'Not needed for sandbox identities.' An agent can identify both the purpose and the relevant boundary versus sibling identity tools.

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 clearly says when the nonce is required ('Every signed identity call needs a fresh nonce') and when it is not ('Not needed for sandbox identities'). However, it does not name the alternative tool or flow for sandbox identities, so an explicit alternative is missing.

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 to lean on, the description carries the full burden and does well: it discloses key expiry (7 days), the rate limit (20 requests/min), and an abuse limit (5 per IP per day). It omits whether authentication is required and does not describe the returned key material, but the operational constraints an agent needs are present.

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 dense sentence, front-loaded with the verb and resource, followed by constraints. Every clause earns its place and there is 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 low-complexity tool with one optional parameter and no output schema, the description covers the key behavioral facts an agent needs (expiry, rate limit, daily cap, intended consumer). It could note the returned value since there is no output schema, keeping it just short of 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 100% and the single optional 'label' parameter is fully documented there. The description adds no meaning about the parameter, so the baseline of 3 for a fully-covered schema is appropriate.

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+resource: 'Get a free self-serve test API key,' with clear qualifiers (7-day expiry, 20 req/min). It is distinguishable from identity_status and other identity_* siblings, though it does not explicitly differentiate itself from registry_create_api_key, which also mints keys.

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 names the intended use — as the api_key for identity_status — and offers the alternative it replaces: 'instead of paying via x402.' That is a clear use-context with an alternative, but it stops short of stating when NOT to use it (e.g., for production keys vs registry_create_api_key).

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 but does disclose meaningful traits: cost ('Free'), key algorithm (RS256), that keys are public, and that sandbox uses a separate key set. It omits caching/rotation and rate-limit behavior, which matter for a JWKS endpoint, so it is 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?

Two tightly packed sentences, front-loaded with what the endpoint returns and followed by the sandbox caveat. No filler or redundant restatement.

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 single-parameter, no-output-schema key-fetch tool, the description covers purpose, cost, and the sandbox variant, which is sufficient to call it correctly. Naming it a JWKS implicitly conveys the return shape, though the exact response format is not spelled out.

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 100% and the single param is already documented with its issuer value in the schema. The description restates the sandbox behavior and adds only that sandbox keys sign sandbox assertions, so it clears the baseline without adding much beyond 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 resource (public RS256 keys) and its use (verify an assertion_token locally), which is concrete and actionable. It does not differentiate itself from the nearby sibling identity_get_test_key, so it stops short of 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?

Gives implied context ('to verify an assertion_token locally') and a routing hint for the sandbox variant, plus a cost note ('Free'). It never states when to prefer this over identity_get_test_key or identity_status, leaving sibling selection 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 full burden. It usefully discloses that it never signs, that a signature is required, and that registration requires no stake, which is real behavioral context. However it omits what happens on success, whether the wallet becomes permanently bound, idempotency, and any auth/error behavior — notable gaps for a 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?

Three compact sentences, with the scope constraint front-loaded and the sibling routing last. Every sentence earns its place; 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?

Covers the prerequisite chain and sibling differentiation well for a 3-required-param mutation with no annotations and no output schema. It stops short of describing the post-registration state or return, which is the main remaining 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?

Schema coverage is 100%, so each of wallet, nonce, and signature is already documented. The description reinforces nonce freshness and signature-over-message semantics but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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 (register) and resource (REAL wallet/identity), and explicitly names the sibling it is not — sandbox identities go to identity_sandbox_register. An agent can distinguish it from identity_get_nonce and identity_sandbox_register 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?

Explicitly gives the prerequisite flow (sign over identity_get_nonce's message), a key constraint (no stake required), and the alternative route for sandbox identities. Nothing about when to pick this tool is left 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?

No annotations exist, so the description carries the full burden, and it does most of it well: no signing, no body, results signed with a separate sandbox key (identity_jwks sandbox=true), never reported as verified, and a concrete rate limit of 10 per IP per hour. It leaves minor gaps such as whether repeated calls mint multiple wallets or are idempotent, 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 the decisive routing cue ('START HERE'), then the return values, then the follow-up chain, then caveats and the rate limit. Every clause carries information an agent needs; nothing is padding despite the density.

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 no annotations, no output schema, and zero parameters, the description must supply routing, return semantics, downstream usage, trust level of results, and quota — and it covers all of these. An agent has everything required to call it and correctly interpret what comes back.

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 of 4 applies per the rubric. The description explains the call's output/return artifacts (sandbox wallet + sandbox_token) and how they feed downstream calls, which is the relevant semantic content for a no-arg 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 (registers/creates a sandbox wallet and token) and immediately distinguishes itself from siblings with 'START HERE if you have no wallet or cannot sign messages,' implicitly separating it from identity_register which requires a real wallet. An agent can pick this over identity_register/identity_get_test_key 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 condition for use ('no wallet or cannot sign messages'), names the follow-up chain (identity_get_challenge then identity_submit_response with wallet + sandbox_token), and names the alternative ('Use a real wallet for an accountable identity'). When-to-use, what-to-do-next, and when-not-to-rely-on-it are all present.

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 meaningful behavior: the no-signature read model, the x402/api-key auth options, and the important sandbox caveat that sandbox wallets are never `verified` and instead report sandbox:true and sandbox_verified. It lacks details on rate limits or failure modes, but the auth and sandbox semantics are genuinely useful.

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?

Three tight sentences, front-loaded with the core question and only then moving to payment/auth and the sandbox edge case. No filler, though the second sentence is information-dense enough to slow parsing slightly.

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 two-parameter, no-output-schema query tool, the description covers the essential semantics: what is being checked, how to authenticate/pay, and how sandbox results differ. The only gap is the exact shape of a successful non-sandbox response, which is implied by the `verified` and `sandbox_verified` fields.

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 100%, so the baseline is 3, and the description goes beyond the schema by explaining api_key provenance (identity_get_test_key) and the IDENTITY_API_KEY environment-variable alternative, which the schema's 'Optional x-api-key' note does not mention.

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 question the tool answers — whether a wallet holds a valid, unexpired assertion — with a clear resource (wallet identity/assertion). An agent can distinguish it from sibling read tools like reputation_status or identity_jwks, though the description never explicitly contrasts 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?

Explicitly describes the access paths: no signature required, pay via x402, or pass api_key obtained from the named sibling identity_get_test_key / IDENTITY_API_KEY env var. It does not say when to prefer this over reputation_status or reputation_query, so it stops 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 provided, the description carries the full burden and does well: it discloses scoring outcomes, that the assertion_token is short-lived and JWT-signed, and a critical replay-protection constraint (fresh nonce, not the challenge nonce). It doesn't cover failure modes or rate limits, keeping it off 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?

Three dense clauses with no filler; the outcome/scoring and the returned token are front-loaded, then the two auth paths are contrasted compactly. Slightly dense but every sentence 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 6-param mutation-style tool with no annotations and no output schema, the description covers the key agent needs: how to authenticate in each mode and what a pass yields. Missing only error/retry behavior and sandbox pass semantics, minor 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 100%, so all six parameters are already documented in the schema, including the real-vs-sandbox split. The description largely restates that split rather than adding syntax, format, or edge-case meaning beyond it, so the baseline 3 applies.

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 (submit response) and resource (a challenge answer) plus the outcome semantics (scored pass/fail/inconclusive) and the artifact produced (short-lived signed assertion_token JWT). This clearly distinguishes it from identity_get_challenge, identity_get_nonce, and identity_jwks among the identity siblings.

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 concrete routing: real wallet requires a DIFFERENT fresh nonce than identity_get_challenge used, sandbox requires wallet + sandbox_token, and the token is verifiable via identity_jwks. It doesn't state explicit when-not-to-use conditions, but the two auth paths are clearly laid out.

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 declares irreversibility ('PERMANENTLY'), explains what is destroyed (all versions by default), and what is retained (an audit row with no content). It omits auth/permission requirements and the response shape, keeping it short of 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?

Three tight sentences, front-loaded with the destructive nature and scope default; every sentence carries information. The '[Wicked Memory]' prefix is the only minor overhead.

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 destructive tool with no output schema and no annotations, the description covers permanence, scope defaults, and retention policy. It lacks any mention of the signature/nonce authorization flow or error behavior, but is otherwise sufficient to call it 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 100%, so the schema already documents every parameter including the scope enum-like values. The description reinforces scope behavior but adds no new syntax or format detail beyond the schema, making the baseline 3 appropriate.

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 ('PERMANENTLY hard-delete a memory') with clear scope semantics, and the 'right-to-be-forgotten' framing distinguishes it from softer siblings like memory_update or memory_deletions. An agent can identify it as the destructive memory operation without ambiguity.

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 explains the scope parameter's default and effect, which is genuine usage guidance, but it never states when to prefer delete over memory_update or what prerequisites (signature/nonce flow) are needed. Usage is implied rather than explicit, with no alternatives named.

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 does disclose one meaningful behavioral trait: the log never contains content, only metadata. However, it omits that this is a read-only operation, the authentication/signature requirement implied by the wallet/nonce/signature params, and any pagination or scope 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 tightly written sentence that front-loads the tool's identity and then its contents. No filler, though it is brief enough that it could have afforded one clause of usage guidance.

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 read tool with no output schema, the description usefully sketches the return shape (ids, times, reasons, never content), and the auth parameters are fully documented in the schema. It is nearly complete, missing only explicit usage routing and the read-only characterization.

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 100%, and each parameter is documented in the schema, so the baseline is 3. The description adds no parameter-level detail; 'ids, times, reasons' describes return values rather than inputs.

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 names a specific resource ('deletion audit log') and enumerates its contents (ids, times, reasons; never content), which is enough to distinguish it from the general memory_history sibling. It stops short of explicitly contrasting itself with memory_history or memory_delete, so it is clear but not fully differentiated.

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 when-to-use guidance, no mention of prerequisites, and no reference to the closely related memory_delete/memory_history tools. The agent must infer that this is the read-side counterpart of deletion operations.

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 does disclose one genuinely non-obvious behavior: another wallet's memory and a deleted id both return an identical 404, so the tool cannot be used to probe for existence. It stops short of describing the return payload (no output schema) or the memory_prepare/signature prerequisite, so gaps remain.

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 resource and lookup key front-loaded and the error semantics appended without wasted words. Nothing could be trimmed without losing 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 five-parameter, all-required tool with no output schema, the description leaves the return shape undefined and omits the memory_prepare prerequisite workflow entirely. It covers identity scoping and error behavior adequately but is thin on what the agent actually receives back.

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 100%, including the cross-reference that nonce/timestamp/signature come from memory_prepare, so the schema already does the work. The description adds nothing about parameter format or the single-use nature of the nonce beyond what is structured.

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 ('Fetch one of your memories by id'), which cleanly separates it from memory_search, memory_history, and memory_delete in the sibling list. The parenthetical adds the key scope constraint that only own, non-deleted ids resolve.

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 'by id' – the agent can infer this is the direct-lookup counterpart to memory_search – but no alternative is named and no when-not condition is stated. It never says to prefer memory_search when the id is unknown.

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 does disclose the return ordering and the temporal/supersession fields the chain contains. However it says nothing about the read-only nature of the call, pagination, or whether chains can be long, so behavioral coverage is partial.

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, front-loaded with the resource and return shape, with zero filler. Every clause (chain scope, ordering, returned fields, id flexibility) 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 read-only lookup with no output schema, the description adequately explains what comes back (full chain, ordering, temporal fields) and how to address it. Minor gaps remain around pagination or chain-size limits, but nothing essential to calling 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 100% and the schema already states memory_id is "UUID of any version in the chain," so the description's note that it works from any version's id adds little beyond the structured field. Baseline 3 is appropriate.

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 returns the full version chain for a memory, with concrete returned fields (valid_from/valid_until/superseded_by) and ordering (oldest first). It is distinguishable from memory_get/search by describing a chain rather than a single record, though it never names those siblings 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?

"Works from any version's id" is the only usage signal, and it usefully tells the agent it need not supply the root version. There is no explicit when-to-use-this-vs-memory_get guidance or mention of prerequisites, so usage is only implied.

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 signing scheme (EIP-191 personal_sign), the ephemeral 5-minute timestamp window, and the single-use nonce that forces a fresh prepare for every call. These are exactly the behavioral traits an agent must know before invoking, none of which appear in structured fields.

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?

Three sentences, front-loaded with purpose and the critical 'prepare again for every call' constraint. Every clause adds actionable information with no repetition.

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 negotiation/prepare tool with no output schema, the description states what is returned (message_to_sign plus timestamp and nonce) and the full signing protocol. Nothing an agent needs to call 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 100%, so the baseline is 3, but the description adds real meaning: `operation` selects which memory_* tool will be called, and `params` are the arguments forwarded verbatim to that tool, which the schema only hints at. It does not enumerate the operation-to-tool mapping values, but the schema's enum-style list covers that.

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: returns the exact `message_to_sign` for the Wicked Memory signing flow, and its position as 'step 1 of every call'. It is unmistakably distinct from the memory_store/search/get/update/delete siblings it feeds into.

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?

Explicit when-to-use and sequencing: sign the message with EIP-191 personal_sign, then call the matching memory_* tool with the SAME arguments plus the returned timestamp, nonce and signature. It also states the operating constraints (timestamp within 5 minutes, single-use nonce, re-prepare for every call), leaving 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 the full burden and does so well: it discloses metering, the exact 402 http_status behavior, the x402 v2 payload location, the price and network (0.001 USDC on Base), and the non-obvious retry semantic that a 402 does not consume the nonce. That is precisely the behavioral context an agent cannot infer from the 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?

Two tight sentences, purpose front-loaded, payment mechanics second. No wasted words while still conveying the retry constraint.

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, 5-required tool with no output schema, the description covers the payment/auth behavior thoroughly. It stops short of describing the prepare-then-search prerequisite chain and the shape of search results (matching, ranking, pagination), which are the remaining 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 100%, so all 12 parameters are documented in the schema itself; the baseline is 3. The description only ties payment_signature to the 402 retry flow, adding marginal meaning beyond that, and explains none of the other parameters.

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: 'Semantic search over YOUR memories only, ranked by real cosine similarity.' The 'YOUR memories only' scoping and cosine-similarity ranking distinguish it from sibling reads like memory_get or memory_history, though it never names 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 strong guidance on the paid invocation path (free with MEMORY_API_KEY, otherwise pay and retry with the SAME arguments plus payment_signature), but gives no guidance on when to choose this over sibling tools such as memory_get or memory_history, nor that memory_prepare must run first to obtain nonce/timestamp/signature.

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 discloses the rate-limit scheme ('free, fair-use rate limited') and a behavioral trait beyond the schema ('a real embedding is computed at write time'), which is meaningful context for a write operation. It does not state durability, whether writes are idempotent, or what the response contains, but the annotation-free gaps are partially 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?

Two compact sentences that front-load the purpose and immediately follow with the precondition. The '[Wicked Memory]' prefix is mildly redundant with the tool name, keeping it from a 5, but there is no waste otherwise.

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-parameter write tool with no annotations and no output schema, the definition covers the critical cross-tool precondition and the embedding side effect. It does not explain the return value or failure modes (e.g., nonce reuse, signature mismatch), but the schema and the memory_prepare reference fill most of the 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?

Schema description coverage is 100%, so the schema already documents all 8 parameters including the memory_prepare-derived nonce, timestamp, and signature. The description adds only the cross-tool instruction to fetch these from memory_prepare, which is moderately useful but not new field syntax. Baseline 3 applies when the schema does the heavy lifting.

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 ('Store a memory') and distinguishes itself from siblings like memory_search/memory_get/memory_update. The bracket-prefixed namespace and 'a real embedding is computed at write time' further pin down what happens, so an agent can tell this is the write path of the memory family without opening schemas.

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 a concrete required precondition: 'Run memory_prepare with operation "store" and these same arguments first.' That is a clear when-to-use signal and names the sibling to call beforehand. It stops short of saying when NOT to use it (e.g., instead of memory_update for existing records), so it falls just below 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?

With no annotations, the description carries the full burden and discloses key mutation semantics: creates a new version, closes the old one via valid_until/superseded_by, omitted fields carry over, and a 409 error if updating a non-current version. It does not mention auth requirements (nonce/signature from memory_prepare) or rate limits, but those are covered by the 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?

Two sentences with zero waste. The versioning differentiator is front-loaded, followed by the carry-over rule and error condition, making the key behavior immediately clear.

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 versioned mutation tool with no output schema and no annotations, the description covers versioning, partial updates, and error conditions well. It omits any mention of the return value (e.g., the new version ID) and does not reference the memory_prepare dependency, though the schema documents the nonce parameter.

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 100%, so baseline is 3. The description adds meaningful semantics beyond the schema by stating that omitted fields carry over, clarifying partial-update behavior for content, tags, metadata, and source.

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 (update) and resource (memory), and immediately clarifies the non-overwriting versioning behavior, distinguishing it from memory_store (which creates new memories) and memory_delete.

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 implies usage by explaining versioning and the constraint that only the current version can be updated (409 otherwise). However, it does not explicitly name alternatives like memory_store or memory_delete, nor does it state when-not-to-use conditions beyond the current-version restriction.

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 that settlement is USDC direct to payTo, that upstreamUrl proxies paid requests to a backend, that changes go live in ~20s, and that PAYWALL_API_KEY is required. It does not describe reversibility or the response, but the operational profile is unusually well surfaced 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?

Three tight sentences, zero filler, front-loaded with the core action followed by settlement/proxy behavior and then the timing/auth constraint. Every sentence carries distinct 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 an 8-param create tool with no annotations and no output schema, the description covers purpose, side effects, latency, auth, and settlement flow. The only gap is return-value/confirmation behavior, which is minor since no output schema is declared.

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 100%, so baseline is 3, but the description adds meaning beyond the schema by explaining what upstreamUrl actually does (proxies paid requests to your backend) and confirming USDC settlement to payTo. This clarifies the two most consequential params rather than merely restating them.

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: 'Paywall a new endpoint with x402 pay-per-call.' The 'new endpoint' framing distinguishes it from paywall_update_route/paywall_delete_route/paywall_list_routes, but it never names those siblings 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?

There is no explicit when-to-use guidance and no reference to alternatives such as paywall_import_routes or paywall_update_route. The agent must infer the create-vs-update-vs-import choice from the name alone, and nothing states prerequisites or exclusions beyond the API key note.

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 usefully discloses the ~20s propagation delay and that PAYWALL_API_KEY is required, which is real behavioral context beyond the schema. However, for a destructive operation it omits irreversibility, confirmation requirements, and effects on in-flight traffic.

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 front-loaded sentence with zero waste: purpose first, followed by the two operational caveats. Appropriately sized for a one-parameter tool.

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 tool with no output schema and no annotations, the description covers the essential calling context: what it does, the auth requirement, and the propagation timing. It stops short of addressing destructive/irreversible semantics, which a delete tool could reasonably note.

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 100%; the sole parameter is documented as 'Route id from paywall_list_routes'. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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 ('Remove a paywalled route') and clearly distinguishes itself from siblings like paywall_create_route, paywall_update_route, paywall_import_routes, and paywall_list_routes. An agent can select it without ambiguity.

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 'Remove a paywalled route' and the schema's reference to paywall_list_routes as the id source, but there is no explicit when-to-use versus alternatives (e.g., update vs delete) or precondition guidance. Adequate but not instructive.

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. It does disclose one genuinely useful fact outside the (empty) schema: the call requires PAYWALL_API_KEY. However, it says nothing about whether the operation is read-only, what the tenant record contains, or how auth failures surface.

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 short sentence with the grouping tag '[x402 Paywall]' front-loaded and the auth prerequisite appended. Nothing is wasted, though the terse phrasing leaves the reader with only a name-level understanding.

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 no output schema and no annotations, the description is the only source of information about this call, and it stops short of describing what a tenant record contains or what happens on a missing/invalid key. Adequate for a zero-parameter read, but thin for a tool whose output shape is otherwise undocumented.

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 convey; the baseline for a parameterless tool is 4. The description correctly implies no inputs are required.

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 (tenant record) and adds the scoping word 'Your,' clarifying this returns the caller's own tenant rather than an arbitrary one. It is clear but offers no explicit differentiation from the other paywall_* siblings beyond the resource name.

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 when-to-use guidance, no mention of alternatives, and no conditions under which this should or should not be called. The only guidance is the parenthetical prerequisite '(needs PAYWALL_API_KEY)', which is a requirement rather than usage direction.

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 the two most important traits: PAYWALL_API_KEY is required, and upsert is keyed on (method, path). It does not say whether routes omitted from the payload are deleted or preserved, nor anything about error/partial-failure behavior, which matters for a bulk mutation.

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?

One sentence, front-loaded with the tag, verb, key, and payoff, with the auth caveat appended compactly. 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?

For a one-param bulk mutation with a fully covered schema and no output schema, the description covers purpose, auth, and keying adequately, but leaves the critical merge-vs-replace semantics and return behavior unaddressed.

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 100% and the single 'routes' parameter is fully documented field-by-field, so baseline 3 applies. The description's keying note adds minor meaning but does not extend the per-field documentation.

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 (bulk upsert) and resource (routes) plus the keying semantics (method, path), and 'paywall a whole API in one call' cleanly distinguishes it from the single-route siblings paywall_create_route and paywall_update_route.

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?

'Bulk upsert ... a whole API in one call' clearly signals the context (many routes at once) and names the auth prerequisite, but it never explicitly routes the agent to paywall_create_route/paywall_update_route for single-route cases.

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 authentication requirement (PAYWALL_API_KEY), which is real behavioral context, but says nothing about scope of results, pagination, or filtering. A read operation is implied but not 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?

A single compact sentence with the namespace tag front-loaded and the auth caveat in parentheses. Efficient, though the namespace bracket is somewhat redundant with the tool name prefix.

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 no-parameter, no-output-schema listing tool, the description covers the essentials: what it returns and that it needs an API key. It could add whether it returns all routes and in what form, but little else 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?

The tool takes zero parameters, which is the baseline 4 per the rubric. The empty schema leaves nothing to document, so no compensation is required.

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 ('List your paywalled routes') and namespaces it under x402 Paywall. It is distinguishable from siblings like paywall_list_settlements by the 'routes' resource, though it does not explicitly contrast 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?

There is no explicit when-to-use guidance or routing against alternatives such as paywall_create_route or paywall_list_settlements. The reader must infer that this tool retrieves the user's registered routes.

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 does disclose the auth requirement and that data is real on-chain USDC settlement records. It does not state pagination behavior, ordering, or whether results are read-only (implied by 'list' but not stated), leaving notable gaps for an annotation-free 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?

A single compact sentence with the module tag front-loaded and the auth caveat trailing. It is appropriately sized, though the parenthetical '(earnings)' is slightly redundant with 'USDC settlements'.

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?

No output schema and no annotations, so the description should do more, e.g., describe the returned settlement shape or pagination. For a simple one-param list endpoint it is barely adequate but leaves the read semantics and result format to inference.

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 100% with a single 'limit' param that the schema already documents as 'Default 50, max 200'. The description adds nothing beyond the schema, so the baseline 3 for full coverage is appropriate.

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 resource ('real on-chain USDC settlements') and clarifies them as 'earnings', so an agent understands this returns settlement data rather than routes or tenant config. However, the listing/aggregation verb is only implied by the name, and it doesn't explicitly distinguish itself from paywall_list_routes beyond the resource noun.

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 only guidance is the prerequisite '(needs PAYWALL_API_KEY)', which is helpful for auth. There is no statement of when to use this versus other paywall list endpoints, nor any conditions on when not to call it.

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 delivers strong disclosures: the key is returned ONCE (a non-recoverable, effectively non-idempotent output) and the call is rate-limited to 5/hour per IP. It stops short of stating what happens on duplicate name/slug or whether the account is immediately active, so it is not fully transparent.

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?

Three tight sentences, front-loaded with purpose, then the critical return-value caveat, then the rate limit. Zero waste; each clause carries actionable 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 2-param, no-output-schema tool, the description covers the one return value an agent must know (the one-time apiKey) and the operational limit. It lacks error/conflict behavior and any note on whether credentials are required, which is a minor but real gap given there are no annotations to fall back on.

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 100%, and the schema itself documents both name and slug constraints including the slug-to-mount-path mapping. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 ('Create a tenant account') and scopes it with the [x402 Paywall] prefix, clearly distinguishing it from the read-side sibling paywall_get_tenant. An agent can tell immediately this is the account-provisioning tool.

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 purpose plus the follow-up instruction to store the key and set PAYWALL_API_KEY, which tells the agent what to do after calling. However, it names no alternatives or prerequisites (e.g. that this must precede authenticated paywall_* calls), leaving the when-to-use routing 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 disclose two genuinely actionable traits: an auth requirement (PAYWALL_API_KEY) and propagation latency (changes go live in ~20s). It stops short of saying what happens to fields that are omitted in a partial update, or whether the change is reversible.

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 front-loaded sentence: the tool family tag, the operation, examples of what changes, the live-propagation caveat, and the auth prerequisite. No filler or restatement of the name.

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-parameter mutation tool with no annotations and no output schema, the description covers purpose, auth, and propagation timing well. The remaining gap is PATCH semantics — whether omitted fields are left untouched or cleared — which an agent needs before performing a partial update.

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 100%, so every parameter (id, path, asset, payTo, price, method, network, description, upstreamUrl) is already documented in the schema. The description only names two of the updatable fields as examples and adds no format or syntax detail beyond the schema, so the baseline of 3 applies.

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 ("Partial update of a route") and gives concrete examples of what can change (price, payout wallet). It implicitly separates itself from paywall_create_route/paywall_delete_route/paywall_list_routes via the update semantics, but never names an alternative 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?

Usage is implied — modify an existing route identified by id — and the prerequisite (needs PAYWALL_API_KEY) is stated, which is useful. However there is no explicit when-to-use/when-not guidance or routing to a sibling tool for related operations.

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 does: the key is returned only once, must be stored, has a wr_ prefix, is capped at 3 active keys per wallet, and past the daily cap calls fall back to x402. These are non-obvious operational constraints an agent could not infer from the 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-loads the step and purpose, then constraints, then downstream usage in dense sentences with no filler. 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?

With no output schema and no annotations, the description still covers the return value (wr_... key, single display), storage obligation, rate/limit behavior, and fallback path. Nothing needed to call this correctly and use the result 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 100%, so the baseline is 3. The description goes beyond the schema by clarifying that the signature must be YOUR (caller's) signature and that it signs the message produced by registry_onboarding_message, and that timestamp is the one returned with that message — meaningful provenance the schema fields do not state.

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 ('create' an 'API key') and frames it as 'Step 2' of a multi-step flow, explicitly distinguishing it from Step 1 (registry_onboarding_message). An agent can tell exactly what this does and where it sits in the sequence 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 states the inputs required and their origin ('wallet, the timestamp and YOUR signature over the message from registry_onboarding_message(action=api_key)'), and names the downstream consumers (registry_search_tools / registry_tool_detail) so the agent knows when to reach for this versus the 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 full burden. It usefully discloses access characteristics ('Public and free' – no auth or payment required), but says nothing about how many results are returned, how 'top scored' is computed, ordering, or refresh/caching 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?

Two short fragments, fully front-loaded, with zero filler. Every word carries 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 parameterless listing tool with no output schema, the description should at least characterize the return set (size, ordering). It conveys scope and access but leaves the result shape entirely unspecified.

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. There is nothing for the description to clarify beyond the fact that no filtering input is accepted, which is implicit.

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 resource and scope: top-scored active tools from the Wicked Registry. An agent can identify it as a ranked-listing tool, though it doesn't explicitly contrast itself with sibling registry_search_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?

There is no indication of when to call this versus the other registry_* siblings (search, detail, badge, report). No prerequisites or exclusions are 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 full burden, and it does add real behavioral context: 'Free lookup... No key or payment,' which tells the agent no auth is needed. It says nothing about rate limits, result ordering, or whether the headline score is cached/live, so the disclosure is partial.

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 dense, front-loaded sentences that cover purpose, cost model, use case, and follow-up tools with no filler. The parenthetical parameter list makes it slightly crowded but still efficient.

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?

No output schema exists, and the description compensates by naming the returned fields ('id and headline reliability score'). With no annotations and 75% schema coverage, it is largely self-sufficient; only the limit parameter and any ordering/pagination behavior remain undescribed.

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 75%, so most parameters are already documented in the schema. The description restates q, endpoint and category semantics but adds little syntax or format detail beyond the schema, and omits the limit parameter entirely. Baseline 3 is appropriate.

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 concrete verb and resource ('find a tool's id and headline reliability score') and enumerates the three lookup keys (q, endpoint, category), so an agent knows exactly what it returns. It does not, however, differentiate itself from the close sibling registry_search_tools, which sounds like an overlapping discovery tool.

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 explicit context ('check a tool before your agent pays it') and a next-step chain ('follow with registry_tool_badge or registry_tool_detail'). It stops short of saying when NOT to use it or how it differs from registry_search_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 burden and does well: it discloses the return content (a message plus timestamp), the ~1 hour validity window, and that it never signs anything. It omits what the caller does with the signed message (the submit step), which is a meaningful gap in a no-annotation 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?

Three tight sentences, front-loaded with the step and purpose, then the branch conditions, then a safety clarification. 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?

No output schema or annotations exist, so the description must (and largely does) cover the return value, validity, and per-action requirements. It stops short of describing the downstream step that consumes the signature.

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 already 75%, but the description adds conditional meaning by binding wallet to api_key and name/endpoint_url to register, clarifying which params apply to which enum branch beyond the flat 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?

States a specific verb+resource: returns the exact message the caller must sign (EIP-191 personal_sign) plus a timestamp. The 'Step 1 of self-onboarding' framing positions it distinctly from write siblings like registry_create_api_key and registry_register_tool.

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 routes between the two actions: action=api_key (needs wallet) for a free API key, action=register (needs name and endpoint_url) to list a tool. That is clear when-to-use guidance, though it never names the follow-up tool or states when not to use this one.

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 usefully discloses the signing model ('This tool never signs'), implying keys stay client-side, but omits idempotency/re-registration behavior, permission requirements for owner_wallet, rate limits, and what side effects registration triggers (synthetic checks, live score). Partial disclosure for a mutation tool with zero annotation coverage.

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?

Three tight sentences with the benefit and the workflow front-loaded; the 'never signs' caveat is placed last as the key security note. 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?

No output schema and no annotations, so the description must cover return values and mutation semantics. It covers the signing workflow well but says nothing about what registration returns (tool ID, score) or how duplicate/updated registrations are handled, leaving real gaps for a 9-param mutation.

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 67%, and the schema already documents protocol, signature, timestamp, schema_url, endpoint_url, and owner_wallet. The description reinforces the signature/owner_wallet relationship but adds no format, validation, or meaning for the undocumented name, category, and description params. Baseline 3, as the schema does most of the work.

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 ('Register a tool you own') plus the outcome ('real synthetic checks and a live score'), which separates it from siblings like registry_report_tool and registry_lookup. An agent immediately knows this is the registration path, not a lookup or report path.

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?

Provides an explicit ordered precondition: obtain the message via registry_onboarding_message(action=register), sign it with owner_wallet, then call this. It names the exact sibling and the argument needed, leaving no inference about when or how to invoke.

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 that the submission is public, rate-limited, manually reviewed, and never auto-suspends a tool, but it omits auth requirements and what the submission creates or returns.

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 short, front-loaded sentences with no waste; the purpose leads and the behavioral qualifiers follow compactly. Minor typo ("behaviour") but structure is efficient.

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 4-parameter write tool with no annotations or output schema, the description covers purpose and key behavioral traits. It still leaves usage routing and auth/response expectations unaddressed, so it is adequate rather than 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 100%, so all four parameters (including the reason values and optional evidence) are already documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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: "File a complaint about a tool's reliability or behaviour." An agent can identify the action, but the description does not explicitly differentiate this from registry siblings such as registry_register_tool 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?

There is no when-to-use guidance or comparison to alternatives. The sentence "Public, rate-limited; reviewed manually, never auto-suspends" describes behavior, not conditions that select this tool over its 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?

With no annotations, the description carries the full burden and does well: it discloses the two auth paths (x402 with 402 payment instructions, or a free API key via param or REGISTRY_API_KEY) and the self-service key bootstrap. It does not cover rate limits, pagination, or result shape, which keeps it below 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?

Three tight sentences, front-loaded with purpose, then auth mechanics, then the keyless recovery path and sibling routing. Every clause is actionable and nothing is repeated.

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 6-param, all-optional search tool with no output schema, the definition covers auth, ranking basis, and fallbacks well. It could still say more about default result shape or pagination behavior, but no output schema exists, so the gap is modest.

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 100%, so the schema already documents sort, limit, category, protocol, min_score and api_key. The description adds only the api_key-overrides-env note, which the schema also states, so baseline 3 is appropriate.

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 (search) and resource (x402/MCP tools) and qualifies the ranking signal (real reliability data: uptime, latency, schema conformance). It also distinguishes itself from the sibling registry_lookup, so an agent can route 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?

Explicitly routes alternatives: use registry_lookup for a quick free check of a known tool, and use registry_onboarding_message plus registry_create_api_key when no key exists. Both the when-to-use-this and when-to-use-something-else conditions are 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 full burden; it does disclose the two behavioral facts that matter most for a lookup — public (no auth) and free (no cost). It says nothing about the score's scale, freshness, or error behavior when a tool_id is unknown.

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 short sentences, front-loaded with the resource and followed by the access constraint. No filler, though the bracket prefix adds little.

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?

There is no output schema, so the description could have explained what the 'composite reliability score' actually is (scale, inputs, freshness). For a simple one-param read tool the core need is met, but the return value is left entirely to inference.

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 100% and the single tool_id parameter is already documented as 'The tool's Wicked Registry id.' The description adds no format or sourcing detail beyond the schema, so the baseline of 3 applies.

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 names a specific resource and attribute — a tool's current composite reliability score — which clearly separates it from siblings like registry_tool_detail or registry_search_tools. It is a noun phrase rather than a verb phrase ('returns/gets'), but the intent 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?

'Public and free' implies no barrier to use, but there is no statement of when to reach for this versus registry_tool_detail (which presumably returns the full record). No exclusions or alternative routing are given.

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 auth/payment requirement ('x402 or a free API key') and what the call returns (score breakdown, component history, health checks). It does not explicitly state read-only behavior, which would be expected for a detail/lookup 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?

Two tightly packed sentences with the payload description front-loaded and the access note trailing. Minimal waste, though the '[Wicked Registry]' prefix is branding rather than informational 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?

Without an output schema, the description does the work of enumerating the returned data, and the access requirement is covered. What remains unstated is return shape/format and any permission granularity, but for a simple two-parameter detail endpoint this is close to 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 100%, so both api_key and tool_id are already documented in the schema, including the env-var override and the origin of the id. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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 the specific resource (one registry tool) and enumerates the payload: full score breakdown, component history, and recent health checks. The retrieval verb is only implied, and it does not explicitly name sibling tools like registry_lookup or registry_search_tools to sharpen the boundary, though the schema's tool_id description partially compensates.

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 phrase 'x402 or a free API key' communicates the access/payment path, which is useful, but there is no explicit when-to-use guidance versus registry_lookup or registry_search_tools. The routing to this tool is only implied indirectly through the tool_id parameter description.

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. 'Search/rank' implies a read-only query operation, which is meaningful signal, but it omits pagination behavior beyond the raw limit param, auth/permission requirements, and the shape of results.

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 tight sentences with the verb and ranking dimensions front-loaded; no padding. The '[Wicked Reputation]' prefix is minor branding noise but does not obscure the core statement.

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-parameter query tool with no annotations and no output schema, the description covers what is being queried but says nothing about return format or result shape. The 100% schema coverage compensates for the filter documentation, but the missing output-schema burden is not picked up.

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 100%, so the schema already documents all 8 filters including the sort prefix convention and limit range. The description's 'every filter is a typed query param' adds no meaning beyond the schema, so baseline 3 applies.

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 (Search/rank) and resource (registered agents) with the dimensions being ranked (tier, stake, reputation, slash history). However, it does not differentiate itself from siblings like reputation_status, reputation_statement, reputation_tiers, or reputation_transparency, so an agent cannot tell which reputation tool to pick 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?

The only usage hint is 'Every filter is a typed query param,' which describes the schema rather than when to use the tool. There is no mention of when this is preferred over the sibling reputation_* tools, no prerequisites, and no exclusion criteria.

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 discloses return composition and one important exclusion, which is genuine value, but says nothing about permissions/auth, whether the read is safe, or any rate limits — gaps a read tool with zero annotation coverage should ideally cover.

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 the primary content (position + ledger) front-loaded and the exclusion appended. The '[Wicked Reputation]' tag prefix is mild noise but nothing is wasted or buried.

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?

No output schema exists, so the description must characterize returns; it names the ledger event types and one exclusion but omits formatting, pagination, or completeness guarantees. Adequate for a simple 1-param read tool, but not thorough.

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?

Single parameter 'wallet' has 100% schema description coverage, so the schema already defines it fully. The description adds no syntax, format, or constraint detail for the parameter. Baseline 3 when schema does the heavy lifting.

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 resource (an agent's full position) plus the concrete contents of the ledger (stakes, unstakes, withdrawals, slashes). It is distinguishable from siblings like reputation_query and reputation_status by content, though it doesn't explicitly name what makes it different from 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?

Adds a scoping exclusion ('Does not include WickedAPI call volume or fees — see the note field'), which implicitly routes the agent for those data points. But there is no explicit when-to-use guidance versus the several sibling reputation_* tools, leaving selection 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?

No annotations are provided, so the description carries the full burden, and it does add real behavioral value: it lists what the payload contains and, crucially, defines the 404 error semantic ('wallet never registered — treat as tier unranked'), which an agent could not infer from schema alone. It omits auth requirements and rate limits, keeping it short of 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 tight sentences with zero filler: the first names the resource and its fields, the second front-loads the critical error-handling rule. 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 read-only single-parameter lookup with no output schema, the description supplies the return fields and error semantics, which is most of what an agent needs. The absence of any auth or read-only statement is a minor 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?

Schema description coverage is 100% for the single 'wallet' parameter, so the schema already documents the 0x address format. The description adds nothing beyond that, making the baseline 3 appropriate.

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 (retrieves) and resource (an agent's current reputation) and enumerates the returned facets: tier, active/unbonding stake, score, slash count, founding-member badge. This differentiates it from siblings like reputation_query, reputation_statement and reputation_tiers, though it never explicitly contrasts 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?

Usage is implied (fetch a wallet's reputation), and the 404-handling note gives a concrete condition for interpreting the result, but there is no explicit when-to-use-this-vs-reputation_query/statement guidance or prerequisites.

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 does disclose that thresholds are admin-configurable and must be read fresh, which is real behavioral context, but it says nothing about auth requirements, rate limits, or whether results are cached — for a zero-annotation tool that leaves significant gaps.

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 short sentences, front-loaded with the payload contents before the freshness caveat; every clause carries information. The bracketed namespace prefix is noise but small.

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 no-input read tool with no output schema and no annotations, the description should describe the returned shape more fully. It names three benefit fields but not the overall structure or whether tiers are returned as a list, so an agent cannot fully anticipate the response.

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 for the description to disambiguate. Baseline 4 applies.

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 concrete resource (tier thresholds and benefits) and enumerates the payload components (min stake, rate-limit multiplier, fee discount), which is far more specific than the name alone. It does not, however, name or distinguish itself from the nearby reputation_status / reputation_statement / reputation_query siblings.

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?

"Read at call time" implies the tool should be invoked when current values are needed rather than relying on cached thresholds, which is useful implied guidance. There is no explicit when-to-use vs. an alternative, and no exclusions or prerequisites.

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 disclosure burden. It implies a passive read of public-facing protocol metrics (no side effects, no mutation), and the field list hints at sensitive surface area (custody model, slash events). However, it never states read-only status, auth requirements, or what 'Live' means in terms of refresh cadence, leaving real gaps.

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 compact sentence with the domain qualifier front-loaded and a colon-delimited field list. Every token carries information; no filler or repetition of the tool name's meaning.

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 no annotations and no output schema, the description does double duty as return-value documentation, which it handles well via the field list. But it omits any routing signal among the sibling reputation_* tools, so an agent choosing between them still lacks the information it needs.

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 has nothing to explain and the baseline is 4. The description's enumeration is about returned fields rather than inputs, which is appropriate here.

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 names a specific resource (Wicked Reputation transparency numbers) and enumerates the exact data exposed — treasury address, custody model, unbonding cooldown, stake, agents, slash events, founding slots — which meaningfully distinguishes it in content from siblings like reputation_status or reputation_tiers. It lacks an explicit verb (e.g. 'returns'), but the scope is still clear enough for an agent to know what it fetches.

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 call this versus the four sibling reputation_* tools, nor any stated prerequisites or exclusions. The agent must infer usage entirely from the field list. That is no guidance, not implied 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 does well: it discloses the verdict taxonomy, that confidence_score is raw consistency, the interpretation policy, auth options (x402 or SANITY_API_KEY), and 429/retry_after rate-limit behavior. It stops short of describing the return payload beyond pointing at `data`.

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?

Densely front-loaded: purpose first, then verdicts, then the action policy, then auth and rate limits, with no filler sentences. It is packed into a few clauses, which is efficient though slightly terse.

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?

No output schema exists, and the description covers the key return semantics (verdict values, confidence_score meaning) plus auth and rate-limit handling. It leaves the structure of `data` unexplained, but for a single-claim verifier the essentials are present.

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 100%, so mode, claim, and context semantics are already fully documented in the schema; the description adds no parameter-level detail beyond what is there. Baseline 3 applies when the schema does the heavy lifting.

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 one claim") and the "one claim" scoping implicitly distinguishes it from the sibling sanity_check_batch. It never names that sibling, so the differentiation is inferable rather than explicit.

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?

Provides an explicit decision policy mapping each verdict to an action (act on supported; treat unsupported/insufficient_evidence as unverified; reject contradicted), which is clear when-to-use guidance. It does not say when to prefer the batch sibling or when verification is unnecessary, so no exclusions are given.

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. It discloses batching and hints at a `data` order, but omits whether the operation is read-only, authentication requirements, rate limits, error behavior, and practical differences between grounded and open modes. This is not enough for a tool with zero annotation coverage.

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 and batching limit. However, the second sentence about `data` is cryptic and does not clearly earn its place, making the structure less clean than it first appears.

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 three-parameter tool with full schema coverage and no output schema, the description covers the batching use case and sibling routing. It still leaves the behavioral contract and return shape underspecified; the `data` reference hints at output ordering but is too vague to be 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 100%, so the schema already documents mode, claims, and context, establishing the baseline of 3. The description adds no meaningful parameter semantics and instead references a `data` list that is not in the schema, which is confusing rather than clarifying.

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 up to 50 claims against one shared context in a single call. It explicitly contrasts with the sibling sanity_check, so the agent can distinguish the batch tool from the single-claim tool. The odd `data` sentence adds some confusion but does not obscure the core purpose.

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 says to prefer this over one sanity_check per sentence, which gives a clear routing condition for multiple claims. It does not specify when-not or explain mode selection, but the main alternative is named.

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 well: it states there is no auth/signup requirement, that the score is never a bare safe/unsafe verdict, that flags lacking GoPlus data stay null, and that raw source data is returned alongside the score. This tells an agent how to interpret gaps rather than treating missing flags as safe. It omits rate limits, latency, and the score's numeric range, which keeps it short of 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?

The body is dense and front-loaded, but the opening phrase 'Free, public, no signup — Free, public, no signup' is a duplicated fragment that wastes the most prominent position. One cleanup would move this to a 5, since every other 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?

There is no output schema and no annotations, so the description must explain both safety and return semantics — and it does, covering null handling, raw-data inclusion, and the no-signup access model. What is missing for a risk-scoring tool is the score's scale/direction and any note on caching or freshness of the on-chain data.

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 100%, with both parameters (chain, address) documented including the accepted chain list and EVM chain_id fallback. The description adds nothing about parameter format or constraints, so this is the baseline 3 case where the schema does all the work.

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 names a specific resource (a token contract's risk profile) and enumerates exactly what it aggregates — honeypot, mint/ownership authority, holder/LP concentration, taxes, trust-list status — into one score, which is far more informative than the title alone. It does not explicitly contrast with siblings, but no sibling tool overlaps this domain, so differentiation is implicit rather than stated.

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: an agent infers this is the tool for assessing a token contract's on-chain risk before trading or integrating it. However, there is no explicit when-to-use statement, no when-not-to-use, and no named alternative for related questions (e.g. price or liquidity tools). The 'free, public, no signup' note lowers the cost of calling it but is not usage guidance.

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