Wild Wallet — where agents get a body

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool costs 1¢ USDC on Base and that in DEMO_MODE the payment is simulated, which are important behavioral traits. It does not explain failure behavior or return format, but for a simple demo this is sufficient.

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 three concise sentences, each earning its place: the tool's identity, the cost, and the usage context plus demo mode note. No filler or redundancy.

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

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

Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers purpose, cost, payment rails verification, and demo mode. It does not state what the response contains, but for a greeting demo this is likely self-evident.

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 input schema already provides 100% coverage for the single optional 'name' parameter with a clear description. The tool description does not add any additional parameter semantics beyond the schema, so the baseline of 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 'The canonical x402 hello-world demo' clearly states it is a greeting/payment demo, and the title 'Say hi to Wild Wallet' conveys the action. It distinguishes itself from siblings like listItems and requestMerge by being a payment test, not a data or merge operation.

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 explicitly says 'Useful for verifying your MCP client can pay Wild Wallet's public rails before you commit to a merge,' providing clear contextual guidance on when to invoke the tool. It does not mention alternatives or exclusions, but the use case is well-scoped.

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. It discloses that the operation is a public read-only browse and enumerates the exact return fields, including the popularity count. This adds meaningful behavioral context beyond the schema, though it stops short of discussing pagination behavior, error cases, or section defaults.

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 two sentences, front-loaded with the action and resource, and efficiently includes the return field list. Every sentence contributes to understanding the tool without fluff.

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 listing tool with no output schema, the description explains the row purpose and return fields. However, it omits details about the section enum and the limit parameter's role, which the schema only partially covers. Given the tool's simplicity, this is a minor but notable gap.

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

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

The description makes no mention of the 'limit' or 'section' parameters. Schema coverage is only 50% (section has a description, limit does not), and the description does not compensate for the missing limit explanation, leaving the agent to guess at its meaning.

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

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

The description clearly states the tool's action ('Browse') and resource ('Wild Wallet's public character catalog'), then specifies that each row is a body an agent can propose to become. This goes beyond the name and title, making the purpose unmistakable and distinct from siblings like listItems.

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 provides a clear usage context: browsing the character catalog to see bodies available for adoption. However, it does not explicitly mention when not to use this tool or contrast it with sibling tools like listItems, so it misses the 'when-not/alternatives' criterion for 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 provided, the description carries the full burden. It discloses that the tool returns items (read-only via 'Return') and specifies behavioral details: it returns 'currently-worn and available' items, scoped to a 'given human's closet'. It also implies the items represent what the user 'loves', adding insight into the data's meaning. No side effects or safety concerns are stated, but the read-only nature is clear.

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 two sentences, front-loaded with the main action ('Return...'), and both sentences provide value. The first states the function, the second explains the use case. No wasted words or repetition of the title.

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?

The description is complete enough for a simple list tool with one required parameter. It explains what is returned, the scope (specific user), and the purpose (personalization). It lacks explicit mention of the wornOnly behavior, but the schema and description together give a reasonable understanding. No output schema is present, so return format is not specified, which is acceptable for a list operation.

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 50% (only userId has a description). The description partially compensates by mentioning 'currently-worn and available', which hints at the wornOnly parameter but does not explicitly explain its effect. It does not clarify that wornOnly filters to only worn items, but the mapping is inferable. Baseline 3 is appropriate given the moderate coverage and partial compensation.

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 uses a specific verb + resource: 'Return the currently-worn and available wearable items in a given human's closet.' It clearly distinguishes the tool from siblings like listBodies and previewOutfit by specifying it returns closet items for a target user, and adds context about the merge request 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?

The description provides clear usage context: 'Agents use this to see what a target user already loves so the merge request feels personal.' This implies it should be used before a merge request and for personalization, but it does not explicitly name alternatives or exclusions. It is a clear context without formal exclusions.

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 discloses key side effects: 'On accept, USDC settles on Base via the shared signer (simulated in DEMO_MODE)' and the auth requirement 'Requires X-Agent-Did header.' It also notes the autonomous nature. Missing details on non-accept actions, but it covers the most critical behaviors.

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 concise sentences that front-load the purpose, then usage, then key details. No fluff or repetition. Every sentence adds value.

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 8 parameters, no output schema, and no annotations, this description covers the main flow: opening/continuing, kinds, settlement, auth. But it omits the response format, effects of specific kinds like reject, and fuller parameter semantics. It is adequate but not fully complete.

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

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

Schema description coverage is low (38%). The description adds meaning for 'kind' by explaining propose|counter|accept|reject and clarifies the relationship between negotiationId and toAgentDid. However, it does not elaborate on itemIds, message, currency, or priceCents beyond schema constraints, so compensation is partial.

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?

Description states a specific verb+resource: 'Two agents negotiate a spend without a human in the loop.' It clearly distinguishes from siblings like greet or requestMerge, which serve different purposes. Title reinforces the action.

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 clear context on when to use the tool: 'Pass negotiationId to continue a thread, or omit it plus provide toAgentDid to open one.' It explains the kind actions and required header. However, it does not explicitly state when not to use or list alternatives, so it stops short of a 5.

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

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

Discloses non-persistent behavior explicitly ('Nothing is persisted') and describes the return as the resolved payload, indicating a read-only computation. No annotations exist, so this disclosure is essential. It doesn't cover auth/permissions, but for a simple preview tool the key behavioral trait is 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?

One sentence plus a short declarative sentence. No redundancy, front-loaded with the action and outcome.

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?

The description explains purpose, source of item ids, output payload, and non-persistence. It lacks explicit guidance on when to use versus requestMerge, but for a low-complexity tool with no output schema, the core information is 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 shows two required parameters with types. Description adds that item ids come from listItems and characterId likely identifies a body, but doesn't define the exact domain of characterId or the format of itemIds beyond 'list.' With 0% schema description coverage, this partial compensation yields a score of 3.

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

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

Clearly states it takes characterId and item ids to return resolved HoloStage.accessories payload, with 'Nothing is persisted' distinguishing it as a dry-run preview. The phrase 'if the merge were approved' differentiates it from requestMerge.

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?

No explicit when-to-use or exclusions. 'Dry-run' title and 'Nothing is persisted' imply a preview before merge, but the description doesn't compare to requestMerge or listBodies/listItems.

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

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

With no annotations, the description carries the full burden. It discloses the requirement for the X-Agent-Did header and the flow (human sees the request in an inbox and taps approve/deny). However, it does not explain what happens after approval/denial, error conditions, or whether the request is synchronous – leaving significant behavioral 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?

The description is two sentences, front-loaded with the action, and includes a functional quote. It wastes no words while conveying the core purpose, the human interaction, and an important header requirement.

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

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

For an 8-param tool with no output schema and no annotations, the description explains the central flow but omits the return value, side effects, and what happens after approval. It is adequate for a simple request tool but lacks details needed for full understanding of the tool's 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 75%, so the description is not the primary source of parameter info. It maps key params (priceCents, characterId, itemIds) to the quote, but does not clarify the uncovered params like itemIds or currency. Most of the description's parameter references echo the schema descriptions already present.

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 clearly states the action: "File a merge request" and quotes the exact request message. It specifies the resource (a human's approval) and distinguishes from siblings like listBodies/items, negotiate, and previewOutfit by focusing on the approval workflow.

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 provides clear context for when to use: after finding a body and items, the agent asks a human for money and approval. It implies the use case by the quote and the approval inbox, but does not explicitly mention alternatives or exclusions. Since this tool's purpose is unique among siblings, this is adequate.

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