xRoot token operations

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety is covered; the description's 'Reads only' is confirmatory rather than additive. What it does add is the scope of the underlying lookup — it is a free, external, on-chain report enumerating authority, tax/hook, and liquidity dimensions, which tells the agent this is a network-dependent analysis rather than a local read. No caveats about unknown/unindexed tokens or latency are given, so it is not 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 sentences, front-loaded with the deliverable and its contents, then the parameter rule, then the trigger condition, closing with a one-word safety note. Every clause carries information an agent needs; nothing is padding.

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

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

There is no output schema, so the description must carry the return-shape burden, and it does so by listing the report sections and noting a verdict with a score. With only 2 parameters and full schema coverage that is sufficient to call the tool. It does not cover failure or degraded modes (unindexed token, unsupported chain value), which keeps it from a 5.

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 clears that bar by tying parameter choice to chain: 'On Solana pass the mint address; on an EVM chain pass the token contract address.' That formats the address input by chain in a way the schema only states in compressed form. Minor mismatch: the schema enum offers only 'solana' and 'robinhood' while the prose says 'an EVM chain', so the EVM/label mapping is slightly looser than the enum.

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 ('Run the free risk report on a token') and then enumerates exactly what the report covers: mint/freeze authority, transfer taxes and hooks, permanent delegates, liquidity, holder concentration, and a scored verdict. That enumeration is what separates it from narrow siblings like check_token_tax, check_frozen_tokens, and check_token_delegates, which each cover only one of those dimensions.

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

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

Explicitly names the triggering user intent: 'Use it when a user asks whether a token is safe, a rug, or a honeypot.' That is a clear when-to-use signal. It stops short of the top score because it never names an alternative or an exclusion (e.g., when the narrow sibling checks are preferable), leaving the agent to infer the routing itself.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: results are risk-ranked and specific classes of findings (unlimited allowances, expired permits, flagged spenders) are called out, and it explicitly states nothing is revoked.

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

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

Front-loaded with the core verb and resource, and the opening sentence carries most of the meaning efficiently. The trailing clarification is slightly redundant ('revoking returns nothing' and 'Nothing is revoked' say nearly the same thing), a minor waste.

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

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

There is no output schema, so the description must convey what comes back, and it does: a risk-ranked list with specific flag categories. Combined with annotations covering the read-only profile and a fully documented two-param schema, an agent has everything needed 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% with only two parameters, so the schema already documents 'chain' (single-chain, omittable) and the public 'address'. The description adds no syntax or format detail beyond that, which is the correct baseline when the schema does 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 (list) and resource (standing token approvals on an EVM wallet), plus the scope of what is surfaced: unlimited allowances, expired permits, flagged spenders, ranked by risk. The 'EVM wallet' qualifier clearly separates it from the Solana-flavored siblings (check_frozen_tokens, check_reclaimable_rent, etc.).

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 framing 'A risk read, not money: revoking returns nothing. Nothing is revoked.' sets expectations and rules out a revocation use case, which is useful implied guidance. However, it never names an alternative tool or states conditions for choosing this over a sibling like check_wallet, so routing remains inferred.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=falseholistically. The description reinforces the read-only nature and adds the useful context that closure is permanent, but it does not reveal additional behavioral traits such as pagination, rate limits, or any edge cases in program enumeration.

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 a single, tightly written sentence that front-loads the core purpose and adds the key safety note about permanence. Every word contributes meaning; there is no repetition or 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 single-parameter read-only tool with annotation coverage and a fully documented schema, the description is complete enough. It clearly communicates what the tool reads, why it is safe to rely on, and what information the agent can expect out of the call.

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

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

The input schema fully describes the single address parameter, including that it is a base58 public key and that only public data is accessed, so schema coverage is 100%. The description itself adds no parameter-level meaning beyond what the schema already provides, making the schema the primary source of parameter semantics.

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

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

The description states a specific verb ('Read'), a precise resource ('upgradeable programs a Solana wallet holds the upgrade authority for'), and the data returned ('gross rent their bytecode accounts hold'). This is specific enough to distinguish it from siblings such as check_reclaimable_rent and list_upgrades.

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 context that closing a program is permanent and that this tool only reads, but it never explicitly states when to use this tool versus alternatives. It does not name or contrast sibling tools, so an agent is left to infer usage from the title and purpose.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description still adds real value by clarifying that the SOL figure is a gross deposit 'before fees' and explicitly stating 'Nothing is closed', which prevents misreading it as an action tool in a close-position workflow.

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 covering the action, the resource, and the return semantics, ending with the key constraint. It is dense with em-dash clauses but every clause carries information; nothing is redundant padding.

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

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

With no output schema, the description carries the burden of describing the return and does so: positions by status, a count of closable positions, and the gross SOL deposit they hold. Minor gap is that the possible status values are not enumerated, but for a one-parameter read tool this is largely 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?

Only one parameter, and schema coverage is 100% — the schema already states it is a base58 Solana public key and that no connection or signature is involved. The description adds no additional parameter-level meaning, 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?

Specific verb (read) plus a precisely scoped resource: a Solana wallet's Meteora DLMM and DAMM v2 positions. It distinguishes itself from the many check_* siblings (e.g. check_lp_fees, check_closable_programs) by naming the exact protocol and position type.

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 rather than stated: 'how many can be closed now' and 'what closing them returns before fees' signal this is the pre-close inspection step. However, no alternative is named and the 'by status' phrasing is not explained as a filter or grouping, leaving the agent to infer the trigger conditions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description aligns with them. It adds value by explicitly stating 'Nothing is recovered' and clarifying that the calculation is 'net of fees', which tells the agent the tool does not perform an actual reclaim and that fees are factored in. The phrase 'Public data only; no connection or signature is involved' in the schema also supports the no-side-effects behavior, but the main description reinforces it.

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 verb, but the second clause 'and the SOL recovering them returns net of fees' is grammatically tangled and ambiguous. The meaning can be inferred, but it would be clearer as 'and reports the SOL that recovering them would return, net of fees.' 'Nothing is recovered' is a useful clarifying sentence, so the structure is adequate but not polished.

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 read-only tool with one fully documented parameter and no output schema, the description covers the essential context: what it reads, what it computes, and that no recovery action is taken. It does not describe the return format, but that is not required given the lack of an output schema and the simplicity of the operation. The main gap is the lack of usage differentiation from sibling tools.

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 only parameter, address, is fully described as a base58 public key and notes that it is public data requiring no connection or signature. The tool description itself does not add further parameter semantics, but it does not need to because the schema already provides complete meaning. 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 names a specific verb ('Read') and a specific resource ('program buffer accounts left behind by a Solana wallet's failed or interrupted program deploys'), and it states the calculated result (SOL recovering them net of fees). This clearly differentiates it from siblings like check_reclaimable_rent and check_closable_programs, which target different resource types. 'Nothing is recovered' removes ambiguity about the tool being purely informational.

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 guidance is provided about when to use this tool versus alternatives, and it does not name any sibling tools. The context implies a use case (failed deploys), but there is no mention of when not to use it or how it relates to check_reclaimable_rent or check_closable_programs. The agent is left to infer selection criteria from the tool name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by confirming 'Nothing is unlocked' and noting in the schema that the call involves public data only with no connection or signature. These reinforce but don't substantially extend the annotation coverage — a modest but non-redundant contribution.

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, zero filler. The primary capability is front-loaded and the safety clarification ('Nothing is unlocked') is appended as a concise closing guarantee. Every word 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 single-parameter, read-only tool with fully documented schema and safety annotations, the description covers what it does and the non-destructive guarantee. The only gap is the absence of any return-value format description, but since no output schema exists and the tool's read nature makes expectations fairly intuitive, this is a minor omission.

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 'address' parameter is already documented as a base58 public key with the clarification that only public data is read and no signature is required. The description adds no parameter-specific semantics beyond the schema, 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 uses a specific verb+resource pair ('Read the permissioned (Token ACL) tokens a Solana wallet holds') and adds a distinctive capability — identifying which frozen tokens the holder can unlock itself. This clearly differentiates it from sibling tools like check_token_delegates or check_approvals without needing to open 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 makes the purpose obvious (checking frozen/permissioned tokens and unlock eligibility) and adds a safety note ('Nothing is unlocked'), which implies a read-only vs. action distinction. However, it does not explicitly name alternatives or state when-not-to-use it relative to siblings like check_token_unlocks or search_tokens, leaving some routing inference to the agent.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds explicit clarification that nothing is deactivated or closed, reinforcing the read-only nature beyond what annotations state. It also notes in the parameter schema that no connection or signature is involved, which adds transparency about side-effect-free 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 sentences, front-loaded with the primary action and outputs, followed by a brief note on non-mutability. No filler or repetition; every word 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 read-only tool with one well-documented parameter, the description covers all necessary information: what it returns (counts and rent), and that it does not modify state. The absence of an output schema is compensated by the clear enumeration of result categories.

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% and the parameter description already explains the address is a base58 public key and that it's public data only. The tool description does not add additional parameter-level detail beyond what the schema provides, so a 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?

Description states a specific verb ('Read') and resource ('address lookup tables a Solana wallet owns'), and details the exact outputs (counts ready to close, cooling down, active, and gross rent per group). This clearly differentiates it from sibling check_* tools that focus on other aspects like approvals or frozen tokens.

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 when to use it (when needing lookup table status) but does not explicitly exclude alternatives or state conditions for when not to use it. It lacks comparison to sibling tools like check_closable_programs, so an agent must infer the appropriate context from the name and purpose.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with 'Nothing is claimed' and adds an important behavioral nuance: fees are in many tokens, so the result is a count, never a summed figure. This goes beyond the annotations and prevents a common misuse.

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 short sentences, each earning its place: the first states the action and scope, the second prevents a likely misinterpretation about summing, and the third confirms the read-only nature. 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?

For a simple one-parameter, read-only tool with strong annotations and full schema coverage, the description fully covers the operation, the venues, the output shape ('count of positions, never a summed figure'), and the lack of side effects. Nothing necessary 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% for the single address parameter, which already explains the base58 public key and public-data nature. The description adds no parameter-specific detail beyond the schema, so the 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 opens with a precise verb-resource pair: 'Count a Solana wallet's liquidity positions with trading fees waiting to be claimed,' and further scopes it by venue (Orca Whirlpools, Meteora, locked Raydium). This clearly distinguishes it from siblings like check_dlmm_positions or check_approvals.

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 intended use is clear: when an agent needs to know how many LP positions have claimable fees for a Solana wallet. It does not explicitly name alternatives or exclusions, but the scope and venue list make the appropriate context obvious.

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?

The description adds 'Nothing is closed or moved' and 'Returns counts and net figures in SOL,' which goes beyond the read-only/idempotent/non-destructive annotations by clarifying outcomes and return type. The schema parameter description further reinforces the public, connection-free nature of the call.

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

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

Two tight sentences front-load the action and scope, then add the key safety qualifier. Every phrase earns its place, with no repetition of the title or schema.

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

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

For a simple single-parameter read tool with no output schema, the description covers the input, the read-only nature, the type of result, and the absence of side effects. It stops short of fully spelling out the exact return fields or when to prefer a sibling, but nothing essential is missing for calling 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 coverage is 100%, and the parameter description already explains the address as a base58 public key with no connection/signature. The tool description adds no significant parameter semantics 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 uses a specific verb ('Read') and a precise resource: reclaimable SOL rent from empty token accounts plus post-rent-cut surplus. This clearly distinguishes it from the other check_* siblings, which target different account/program concerns, even though no sibling is named.

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 intended use is implied: call it when you want to know how much rent a Solana wallet can reclaim. However, it gives no explicit when-not-to-use guidance or comparison with sibling check tools, so routing 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?

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description still adds real context: it explicitly reassures that nothing is cancelled and explains the non-obvious rent-routing rule for sponsored subscriptions (rent returns to the sponsor, not the wallet). Return shape is only loosely sketched, so it stops 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?

One dense but well-formed sentence that front-loads the core action and appends the rent nuance and the cancellation reassurance. Nothing redundant, though the parenthetical aside slightly lengthens an already long sentence.

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, the description usefully characterizes what comes back (subscriptions and allowances grouped by state, plus expected rent) and closes the obvious ambiguity about side effects. A brief note on pagination or result volume would make it 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 coverage is 100% for the single address parameter, and the schema already documents base58 format and the public-data/no-signature guarantee, so the description adds little parameter-level detail. 'By state' hints at how results are grouped but does not clarify any input semantics.

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

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

States a specific verb and resource (read on-chain subscriptions and recurring allowances a Solana wallet has granted) plus the secondary payload (reclaimable rent). It is distinguishable from near-neighbors in the sibling list such as check_approvals and check_reclaimable_rent because it scopes both to subscription accounts.

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 only implied: an agent can infer you call this when auditing a wallet's subscription exposure, but the description never says when to prefer it over check_approvals, check_token_delegates, or check_reclaimable_rent, nor any prerequisite. The 'Nothing is cancelled' clause hints at a read-only audit context but is not framed as 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?

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description goes beyond these by explaining that 'revoking returns no SOL' and 'Nothing is revoked', adding context about the financial irrelevance and the absence of side effects. This aligns with and enriches the annotations without contradicting them.

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 concise and effective: two sentences with no redundancy. The core action and target are front-loaded, and the clarifying 'risk read' and 'Nothing is revoked' follow logically. Every word 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 single-parameter read tool with comprehensive annotations, the description is adequately complete. It conveys the tool's purpose, its read-only nature, and the fact that no financial transaction occurs. The output is implied as a list, but explicit format details are omitted; this is acceptable given the simplicity and lack of an output schema.

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 fully describes the 'address' parameter, including that it is a base58 public key and that public data is used. The description does not add additional parameter-specific meaning beyond what the schema provides. With 100% schema coverage, a 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 states a specific verb ('List') and a precise resource ('standing token delegates and approvals on a Solana wallet'), further clarifying the meaning as 'programs still allowed to move its tokens'. This clearly distinguishes it from sibling tools like check_approvals by focusing on standing delegates rather than just checking approvals.

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 that this is a risk read ('A risk read, not money') and that it does not have financial effects, helping the agent understand when to use it. However, it does not explicitly name alternatives or state when not to use it, which is a minor gap given the similar sibling check_approvals.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds 'Nothing is collected.' which clarifies that the tool only lists tax tokens and does not perform any collection action. This extra clarification is useful beyond the annotations, though the annotations already cover the safety profile.

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 a single sentence, though it uses a dash and an extra clause ('— the tokens whose withheld tax that wallet can collect'). It is reasonably concise and front-loads the primary action and resource. No unnecessary words, but the structure could be slightly tighter.

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

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

For a simple read-only tool with one parameter and no output schema, the description is complete. It specifies the input (wallet address), the output (list of tokens and tax rates), and clarifies that no collection occurs. There are no missing details that would prevent an agent from using the tool 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%, and the description does not add additional meaning beyond what the schema already provides. The description mentions 'a Solana wallet' which matches the schema's 'Solana wallet address to read', but adds no new details about the parameter format, constraints, or behavior. Baseline of 3 is appropriate given high coverage.

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 verb 'List' and the resource 'transfer-tax tokens a Solana wallet launched through the platform, with each tax rate'. It also clarifies that it is the tokens whose withheld tax the wallet can collect, and explicitly says 'Nothing is collected.' This distinguishes it from other read-only check tools by focusing on tax-specific data.

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 no guidance on when to use this tool versus the many sibling check_* tools (e.g., check_approvals, check_frozen_tokens). It implies usage for tax-related queries but does not explicitly state a condition or mention alternatives. No exclusions or context 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds a meaningful scope limitation ('Reads public lock accounts only') and lists what each lock reports. No contradiction with annotations.

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

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

Three short sentences with no filler. The core action is front-loaded, and each sentence adds distinct value: function, usage context, and scope limitation.

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 one simple parameter, read-only/idempotent annotations, and no output schema, the description adequately implies the return content by listing the fields each lock reports. Nothing critical is missing for an agent to select and invoke the tool.

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 covers the only parameter (mint) with 100% coverage and a clear base58 description. The tool description adds no additional parameter constraints or formats beyond endorsing that it reads the token's locks, 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?

The description opens with a specific verb and resource ('Read a Solana token's on-chain locks') and enumerates the exact data points returned (supply vesting, locked liquidity, cliff, start, period, released amounts). This clearly distinguishes it from sibling check_* tools like check_token_delegates or check_frozen_tokens.

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 an explicit triggering condition: 'Use it when a user asks when a token unlocks or whether its liquidity is locked.' It does not name alternatives or negative conditions, but the context is clear and actionable.

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?

Annotations already establish readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: each venue is read independently and reports ok/failed/unavailable plus completeness, so a failed read is not mistaken for an empty result. It omits cost/latency of a multi-venue fan-out call, 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?

Purpose is front-loaded in the first clause, followed by the itemized payload and the routing guidance. It is long and reads as one run-on catalog, but nearly every item is load-bearing because the whole point is the union of recoverables.

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 only two parameters, the description carries the burden of telling the agent what comes back, and it does so by listing recoverables and the per-venue ok/failed/unavailable status model. It stops short of describing response shape or ordering for a fan-out result, but is otherwise sufficient for correct invocation.

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

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

Schema coverage is 100% and the chain enum is self-documenting, so the baseline is 3. The description goes further by explaining what each chain value actually returns (Solana rent/surplus/etc. vs EVM LP fees/bridge withdrawals), which gives the 'chain' parameter operational meaning beyond the enum labels.

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 ('read everything a wallet can get back, in one call') and enumerates the concrete recoverables on both Solana and EVM. It also explicitly contrasts itself with the per-venue siblings, so an agent can separate check_wallet from check_reclaimable_rent, check_lp_fees, etc. 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?

It names the exact use case ('what can this wallet recover') and the alternative ('use the per-venue tools for one venue in detail'), drawing a clean line between the aggregate and the specialized tools. Nothing about when to prefer this over the siblings 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?

Annotations already establish readOnlyHint, idempotentHint, openWorldHint, and non-destructive intent, so the bar is lower. The description adds useful context by stating that unwrapping is not performed and that the returned amount is net of fees, which clarifies the tool's behavior without contradicting the annotations.

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

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

The description is two concise sentences with every clause earning its place, and the key purpose is front-loaded ('Read the wrapped SOL...'). There is no filler or redundant repetition of the schema.

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

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

For a one-parameter read-only inspection tool with rich annotations, the description fully covers what the tool does, its key output concept (net-of-fee unwrap value), and its non-mutating nature. No output schema exists, but the description does not need to detail return values for this simple tool.

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% and the single address parameter is already fully documented in the schema, including the base58 public key format and that it is public data. The main description adds no parameter-specific detail beyond that, so a baseline score 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 names a specific action ('read') and a specific resource ('wrapped SOL (wSOL) sitting in a Solana wallet's token accounts'), and clarifies it also reports the net SOL value after unwrapping without performing the unwrap. This sets it apart from siblings like check_wallet or check_token_delegates because the purpose is narrowly scoped to wSOL.

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 when to use the tool by defining it as a read-only inspection of wSOL and explicitly saying 'Nothing is unwrapped,' which warns an agent not to expect an unwrapping side effect. However, it does not state alternatives or conditions for choosing this tool over other wallet/token checkers.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description reinforces this with 'Reads only; nothing is prepared or sent' while adding the useful return-shape detail (decimal strings in the chain's currency). It doesn't note rate limits or whether estimates expire, 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: the first front-loads what is returned, the second covers when to use it, with the read-only caveat last. No filler or restatement 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?

There is no output schema, but the description explains exactly what the response contains (platform fee plus rent/base/priority network fee as decimal strings in chain currency), which is what an agent needs. Combined with 100% schema coverage, nothing material 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 nested request object, its per-service branching and all field meanings are already documented in the schema. The description adds no parameter-level syntax or format detail, so the baseline 3 is correct.

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 (quote) and resource (the exact cost of a token operation), and enumerates the components returned: platform fee plus estimated network fee (rent, base, priority) in the chain's currency. This is unmistakably distinct from the read-only check_* 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?

Explicitly says when to use it: 'when a user asks what a token deploy, authority revoke, airdrop or metadata update would cost,' and frames the timing as 'before anything is built.' It doesn't name an alternative tool for actually performing those operations, but the sibling list contains none, so the routing gap is minor.

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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds value by stating the data is read from the chain and by explaining the state semantics (pending with estimate, active with epoch, not yet queued). This goes beyond the annotations without contradicting them.

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 dense but efficient: the first sentence covers the resource and output states, the second gives the usage trigger, and the third notes the optional filter. Every sentence earns its place and the most important information is front-loaded.

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 read-only tool with one optional parameter and no output schema, the description covers what the tool lists, where the data comes from, what states mean, when to use it, and how to filter. No critical context 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 schema coverage for parameters is 100%, so the schema already fully documents the optional state parameter. The description adds minor value by indicating the filter is 'by mainnet state', but it does not substantially extend the schema's own description.

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 lists Solana protocol upgrades/feature gates with their state across networks, which is a specific verb+resource. It distinguishes itself from all sibling tools, which focus on token/program/wallet checks, and clarifies it covers SIMD/feature activation queries.

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

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

The description gives an explicit use case: 'Use it when a user asks whether a SIMD or feature has activated, or what is coming next.' It provides clear context without listing excluded cases or naming alternative tools, but the sibling set makes alternatives easy to rule 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: the result set is limited to indexed trending/newest tokens, and the audit verdict is cached and present only 'where one exists', warning the agent that data can be 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?

One sentence with an em-dash aside, front-loading the subject matter before the usage hint. Well organized, though the parenthetical about trending/newest is slightly long for the payload it carries.

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 carries the return-value burden, and it does list pool, price and cached audit verdict. Chain coverage caveats remain vague ('May be omitted while one chain's directory is indexed'), but nothing essential for calling the tool 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% for both parameters, so the schema already explains the chain enum and that an empty query returns the trending list. The description restates the same name/symbol/address semantics without adding syntax or format detail, matching the baseline 3.

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

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

States a specific verb (find) plus resource (token) and narrows the corpus to the xroot.dev directory — trending and newest indexed tokens on an EVM chain. It also names the returned fields (pool, price, cached audit verdict), which separates it cleanly from siblings like audit_token or check_token_tax.

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

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

Gives a concrete trigger: resolve which of several same-named tokens a user means, explicitly positioned before auditing it, which routes the agent toward audit_token as the follow-up. It offers no explicit when-not conditions or alternatives for the lookup itself, so it stops just 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.