HeyAnon MCP

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

While annotations cover the destructive nature, the description adds vital context regarding the operational state (stuck/timeout) that necessitates this action. This conditional context is extremely helpful for the agent's decision-making process.

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 highly concise and efficient. It front-loads the primary function and immediately follows with the necessary operational constraints, adding zero 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 destructive, zero-parameter tool, the definition is maximally complete. The usage guidelines fully cover the agent's decision-making pathway, making the invocation highly safe.

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?

Since the input schema is empty (0 parameters), the baseline score applies. The description is perfectly suited for an empty-parameter tool.

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

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

The description uses a specific verb ('Force-stop') and identifies the resource being acted upon ('Anon processing of the current ask_anon request'). This immediately distinguishes it from related tools like 'ask_anon' or 'anon_message'.

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 provides explicit, critical instructions on when to use the tool and when not to. The agent is guided to only use it when 'isProcessing stays true for too long or the request is stuck,' and to use polling otherwise.

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, and closed-world, so the safety profile is covered. The description adds value beyond that by noting it returns entries plus pagination and is also exposed as structuredContent, and by clarifying that the data is informational only and does not constrain transfers.

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

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

Front-loads the purpose, then the usage recipe, then the caveat and return shape. The worked example is long but earns its place by disambiguating the resolve-then-confirm workflow; 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?

Given an output schema exists, the description does not need to enumerate return values, yet it still notes pagination and structuredContent. Combined with the workflow guidance and scope caveat, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes slightly further by showing how the 'search' parameter is actually used ('find the entry by name (search)'), tying a schema field to a concrete agent workflow rather than just restating it.

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 (list the saved recipient addresses / address book) and names the fields returned (name, networks, address). It is clearly distinguishable from siblings like transfer_native, wallet_list, and the portfolio_* 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?

Gives an explicit triggering scenario ('send 0.1 ETH to My work address'), the exact sub-step (find by name via search, take the address, confirm with the user), and names the downstream tools (transfer_native / transfer_asset). It also states the negative case: 'Informational only: transfers are not restricted to these addresses,' so the agent knows this list is not an allowlist gate.

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 cover safety (readOnly/idempotent), and the description goes well beyond them: polling semantics, the status lifecycle, what activity shows while running, the dual text/HTML card representation, and the crucial constraint that in-HTML buttons only navigate while executing actions must happen in the HeyAnon app.

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

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

Front-loaded with purpose and polling instruction, then progressively describes activity, cards, and HTML handling. Dense but mostly earns its length; the return-value enumeration at the end is slightly redundant with the output schema.

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

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

Despite an output schema existing, the description resolves the genuinely ambiguous parts: the status lifecycle, the two content blocks, and how a client should render HTML vs describe text. An agent has everything needed to call and present results.

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

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

Only one parameter with 100% schema coverage whose schema text ('Message ID returned by ask_anon') matches the description's 'by its Message ID'. Nothing new is added, 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 (Get) and resource (state of a message) and ties it directly to the sibling that creates it ('sent with ask_anon'), so an agent can place it in the ask_anon polling workflow 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?

Tells the agent to poll until status is 'done'/'failed'/'aborted' and explains what 'running' means, which is exactly the when-to-use guidance needed. It doesn't explicitly say 'call this after ask_anon returns an id' or give an alternative sibling, but the ask_anon linkage covers most of the intent.

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 flag destructiveHint=true and openWorldHint=true, and the description corroborates that by stating Anon can execute real transactions from attached wallets, so the safety profile and its rationale agree. Beyond that it discloses the asynchronous contract (output is only a Message ID confirmation), the polling cadence (every 2-3 s until 'done', 'failed' or 'aborted'), what 'running' returns, the tasks extension path, and the idle precondition. The statelessness of Anon ('keeps NO conversation context') is a critical behavioral trait an agent could not infer from 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 structure is front-loaded and logical: purpose, execution semantics, async protocol, statelessness, idle check, safety rule, alternative. Given the number of contracts an agent must honor, most of the length is earned, but the 'no conversation context' point is restated (parenthesis plus a full sentence plus schema text) and the parenthetical card/HTML detail could be tightened.

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 the description compensates fully: it names the returned Message ID, the confirmation shape, the reply and cards fields, and how to render and poll them. Error paths, the idle guard, the task-extension variant and the general-research alternative are all covered, so an agent has everything needed to call it correctly on the first try.

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 in explaining that 'text' must be self-contained and in the user's own words and must carry wallet, network, token and amount on every message. It also surfaces the one-per-wallet-type constraint enforced by the backend and the displayName-or-ask resolution rule. It does not add much on 'files' beyond what the schema says, which keeps it out of the top band.

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

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

The opening sentence names a specific verb and resource (sending a request to the 'Hey Anon' on-chain agent) and enumerates the domains it covers: balances, swaps, bridging, lending, staking, CEX, research and automations. It also separates itself from siblings without ambiguity, e.g. 'For general crypto research not tied to the user wallets, prefer ask_gemma' and the polling handoff to anon_message.

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

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

It states when to use (action requests only when the user asked for that action), when not to ('never add actions the user did not ask for', research goes to ask_gemma), and the operational preconditions: the tool errors if the previous request is still processing, so you should poll anon_message or call abort and retry. It also spells out what the caller must NOT do (do not build the transaction, do not look up routes, do not compute amounts, do not split into steps), which is unusually explicit routing 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 and openWorldHint, so the safety profile is partly covered. The description adds meaningful behavior beyond that: synchronous return of answer text, no polling required, no wallet addresses taken, no transactions executed, and an isolated session separate from the Anon conversation. Only the return-shape detail is left implicit.

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, front-loaded with what Gemma is and does, followed by the synchronous behavior and the routing rule. Every sentence earns its place, though the domain enumeration is slightly list-heavy.

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, no-output-schema research tool, the definition covers identity, capability scope, execution mode, session isolation, input format expectation, and sibling routing. 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 coverage is 100% and the single 'text' parameter already carries an example, so the schema does the heavy lifting. The description adds marginal framing (research question, contract-address token analytics, no wallet addresses) but no syntax or format guidance beyond the schema. 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 (Ask) and named resource (Gemma, the Hey Anon crypto research assistant) and enumerates the covered domains: protocol analysis, social insights, market data, news, token analytics by contract address. It explicitly distinguishes itself from the sibling ask_anon, 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?

Provides an explicit routing rule: 'Prefer ask_gemma for general crypto questions and ask_anon for anything about the user wallets or for actions.' This is a clear when-to-use plus a named alternative with the condition that selects 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint), so the description doesn't need to restate them; instead it adds the workflow constraint of checking before a subsequent ask_anon call and states the return shape ('isProcessing: true|false'), which matters since there is no output schema. It doesn't discuss polling frequency or timing/expiry behavior of the processing state, 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?

Three compact sentences with the core purpose front-loaded, followed by the return value and then the usage conditions. No filler or redundant 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 zero-param, read-only status check with no output schema, the description supplies the missing return contract and the routing to abort. Minor gaps remain around whether the state can persist or time out, which an agent might want when deciding how long to wait.

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

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

The tool takes zero parameters, so there is nothing to document; schema coverage is 100% by definition. Baseline 4 applies for a no-argument tool, with no parameter behavior left ambiguous.

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 — checking whether Anon is still processing a prior ask_anon request — and explicitly names the sibling tool (ask_anon) whose state it reports on. It is distinguishable from every other sibling at a glance.

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 both when-to-use conditions: before sending another message, and when a request appears stuck. It also names the follow-up tool (abort) for the stuck case, so the agent knows exactly what to do with each outcome.

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?

Beyond the annotations (destructive=false, openWorld=true), the description discloses what the call returns (a link and short code), expiry behavior (link and login_id expire after 10 minutes), the required follow-up polling of login_status, and the credential prerequisites (access to the user's own account). That is exactly the behavioral context an agent needs before invoking.

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

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

Front-loaded with purpose and return value, then the procedure, then the exclusion, then the triggers. The middle narrative about signing in 'for the user' is lengthy, but each clause maps to a real branch of the flow rather than 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 exists, and the description compensates fully by describing the return payload (link + code, login_id) and how to retrieve the actual API key via login_status. It also covers the failure/fallback path and expiry, so an agent can execute the whole flow without further guidance.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description instead documents the implicit inputs (user's browser/browser session) that drive the outcome.

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 ('Sign in to Hey Anon (or create an account)') plus the mechanism ('through Privy in the browser') and the no-API-key constraint. Readily distinguishable from the login_status sibling, which it explicitly names as the follow-up step.

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

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

Gives explicit triggers (right after installation, tools failing with 'API key not set', user wants to connect) and an explicit exclusion with an alternative ('Not for OAuth connections (ChatGPT apps, Claude connectors)... the user connects with the client's own Connect button'). It even prescribes the degree of autonomy ('go through the whole flow yourself without asking the user to confirm each step').

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 only flag openWorldHint and non-idempotency; the description adds substantial non-obvious behavior: the 25-second blocking wait, the one-time display of the returned API key, the fact that login_id cannot be reused, and the side effect of creating EVM/Solana/TON wallets when the account has none. It also spells out the required follow-up action (save as X-API-Key and reconnect), which annotations cannot convey.

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 action and the polling rule before the status semantics, and every sentence carries operational weight (status handling, key-saving, tasks fallback). It is dense rather than wasteful, though the run-on status enumeration could be tightened 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?

With no output schema, the description fully documents the possible results ('pending', 'completed', 'denied', 'expired'), what each means, and what the agent must do next for each. Nothing an agent needs to invoke and follow through on this 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 coverage is 100% and the single parameter's schema description ('login_id returned by the login tool') is already complete, so the description adds no syntax or format detail beyond it. Baseline 3 is appropriate when the schema fully carries the 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?

Opens with a specific verb and resource ('Finish a login started with the login tool') and immediately distinguishes itself from the sibling `login` by positioning itself as the completion half of a two-step flow. An agent can tell from the first clause that this is the polling/finalization counterpart, not a new authentication attempt.

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

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

Explicitly instructs the agent to keep re-calling while pending and NOT to ask the user for confirmation, then routes to `login` on denied/expired, and names an alternative path for clients with the tasks extension. When-to-use, when-not-to-prompt, and the alternative on failure are all covered.

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 cover read-only, idempotent and closed-world behavior, so the bar is lower. The description adds real value beyond them: the exact return payload ('pong' plus ISO 8601 server time) and that no API key is required, which is meaningful for a tool with no output schema.

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

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

Three short sentences, front-loaded with the purpose and then the return contract. Zero 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 trivial no-param probe with no output schema, the description supplies everything an agent needs: what it does, what comes back, and that no credentials are required. 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?

The tool takes zero parameters, which is the baseline-4 case. Nothing in the description misleads about inputs, and the schema is fully documented by construction.

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 ('Health check for the Hey Anon MCP server') and goes further by naming what it returns ('pong' and server time). No sibling tool is a health check, so the agent can distinguish it immediately.

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 'Health check' strongly implies the use case (verify the server is reachable/alive), but the description never states when to call it versus alternatives or any exclusion. 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?

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: the call fails when multiple EVM wallets exist and no address is supplied, and the response is raw JSON rather than a normalized shape.

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, front-loaded with what the tool returns and followed by the one conditional the caller must know. No filler, though the closing note about raw JSON is minor housekeeping.

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-optional-parameter read tool with no output schema, the description covers source, keying, the conditional requirement, the failure mode, and the raw return format. Only the practical mapping from a wallet to the 'keyed by exchange' result is left implicit.

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 schema description already states that address is required when the account has several EVM wallets, so the description largely restates it while adding the consequence (backend rejection). No extra syntax, format, or default details are added, 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 resource and source: balances and positions from CEX exchange accounts linked to Hey Anon, with Hyperliquid as a concrete example. The 'exchange accounts' framing implicitly separates it from portfolio_defi and portfolio_tokens, though no sibling is named 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?

Provides a conditional prerequisite (pass address when the user has several EVM wallets, or the backend rejects the call), which is useful operational guidance. However, it never says when to prefer this tool over portfolio_defi, portfolio_tokens, or portfolio_transactions, so the selection guidance 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real context beyond them: addresses are auto-derived from wallet_list rather than passed in, and the return payload shape is given as [{ walletAddress, data }]. It does not cover the opaque "data" shape, chain coverage, or failure behavior for wallets that fail lookup.

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 position types and the wallet source are front-loaded, and the return shape is appended compactly. Nothing could be cut 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 parameterless, read-only aggregation tool with no output schema, the description covers what it fetches, where input comes from, and the envelope of the response. Missing only secondary detail such as supported chains, pagination/size limits, and behavior when a wallet has no DeFi activity.

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?

Zero parameters, so the baseline is 4. The description usefully explains why there are none – the address list is sourced internally from wallet_list – which prevents an agent from hunting for a wallet-address argument that does not exist.

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 its scope: DeFi positions (LP, staking, lending, vaults) across every user wallet. The enumeration clearly separates it from a token-holdings or transaction-history tool, but it never names the adjacent siblings (portfolio_tokens, portfolio_cex, portfolio_transactions), so the boundary with them is inferred 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?

"addresses taken from wallet_list" is a useful prerequisite and implies the natural call order, but there is no explicit when-to-use vs portfolio_tokens/portfolio_cex, and no exclusion for empty or unlisted wallets. Usage must be inferred from the scope statement.

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

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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description goes beyond them by disclosing the exact return shape, the EVM-vs-Solana keying asymmetry, and the practical warning that output can be large with many wallets — a useful cost/volume signal not present in 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?

Two sentences, no filler, and the resource scope is front-loaded ahead of the return-format detail. Slightly dense — the return-shape clause packs chain-id keying, Solana placement, and a volume caveat into one sentence — but every element 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, so the description carries the return-value burden and does so adequately (array of { walletAddress, data }, with the EVM/Solana split). The large-output warning is a good operational caveat; only a hint about pagination or handling that volume is absent.

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 and the schema is empty, so there is nothing to document; the description correctly does not invent parameter guidance. The note that wallets are sourced from wallet_list instead explains the implicit input, which is the only parameter-adjacent concept that needed covering.

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 (token balances) and an exact scope: every user wallet, all supported networks. An agent can immediately separate it from the sibling portfolio tools (portfolio_cex, portfolio_defi, portfolio_transactions) which cover exchange, DeFi, and transaction data rather than plain token balances.

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 (need a per-wallet token balance snapshot) and helpfully notes the addresses originate from wallet_list, linking it to a sibling. However, it never states when NOT to use it or which sibling to prefer for a narrower query, so the routing guidance 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?

Annotations already cover safety (readOnly=true, idempotent=true). The description adds genuinely new context beyond them: the return shape [{ walletAddress, data }] and an explicit warning that output can be large when many wallets exist. It stops short of explaining whether results are capped or how to narrow scope, since no parameters exist for that.

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, front-loaded with what the tool returns and followed by the output shape and the size caveat. 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 no-parameter, no-output-schema tool this covers the essentials: what it returns, the per-wallet shape, and the size risk. A note on whether the data is bounded (time window, pagination, truncation) is the only real 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?

Zero parameters and 100% schema coverage, so this is the baseline-4 case. The description correctly does not invent parameter semantics; instead it documents the implicit input dependency (addresses sourced from wallet_list).

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 verb/resource combination: 'Recent transactions for every user wallet'. The scope (all wallets, not a chosen one) is explicit, though it never names sibling tools like portfolio_tokens or portfolio_cex to sharpen the distinction.

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: the note that addresses come from wallet_list tells the agent where wallets originate, but there is no when-to-use versus portfolio_tokens/portfolio_cex/portfolio_defi guidance and no exclusions. Adequate but leaves the routing decision 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 readOnly/idempotent/no-open-world, so safety is covered. The description adds genuine behavioral value by disclosing the shape of the response — a static catalog with names, keys, networks and tool counts — which matters because no output schema exists to reveal that.

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, no filler: the first enumerates what comes back, the second states the use case. The high-value content is front-loaded and 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 parameters, no output schema and annotations covering the safety profile, the description supplies exactly what is missing: the contents of the list and the reason to call it. Nothing an agent needs to invoke it correctly is absent.

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; there is nothing to document or mis-document. The description correctly implies a parameterless browse call rather than suggesting any filtering 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?

States a specific verb ('List') and resource ('the protocols and integrations Anon can operate'), then enumerates the returned fields (name, key, description, supported networks, tool count). No sibling tool covers this ground, so an agent can immediately tell this is the capability/catalog lookup.

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 operating condition: 'Use it to check whether Anon supports a protocol or network before asking.' That is clear when-to-use guidance. It stops short of a when-not clause or naming an alternative tool, which the examples reserve 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds meaningful consequence context beyond the annotations: it is irreversible and the automation will not run again, plus it returns a confirmation. That extra context is the right kind of value-add, though permissions or side effects aren't detailed.

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

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

Two compact sentences with zero filler, and the irreversible consequence is front-loaded ahead of the return note. 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 one-parameter destructive tool with no output schema, the definition covers the essential points: what it does, that it's irreversible, and that it returns a confirmation. Only minor gaps (permissions needed, effect on in-flight runs) remain, and annotations carry the safety profile.

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 'id' parameter, including provenance ('from scheduled_task_list'). The description adds nothing beyond 'by id', so the baseline of 3 applies since 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?

States a specific verb and resource ('Delete (cancel) a scheduled task') with the keying parameter ('by id'), which cleanly separates it from the list/get siblings. An agent can identify the operation 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?

The description implies usage via 'by id' and the schema points to scheduled_task_list as the id source, but it never states when to delete versus alternatives (e.g., abort or pausing). Usage context is implied rather than enumerated.

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 openWorldHint=false, so the safety profile is covered. The description adds genuine value by naming what comes back, notably taskExecutorResponse as 'the last execution result' — context the annotations cannot convey and there is no output schema to carry 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?

A single sentence that front-loads the action and scope, then the id source, then the return payload. No filler or restated boilerplate.

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 enumerates the returned fields and flags taskExecutorResponse's meaning, which is the main ambiguity for a task-detail tool. It does not mention behavior when the id is unknown or invalid, a minor gap given a one-param read-only 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 id parameter is already documented as coming from scheduled_task_list, so the description's identical hint is redundant rather than additive. 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 ('Get one scheduled task') with singular scope, and explicitly contrasts with the sibling that produces the id (scheduled_task_list). An agent can distinguish it from scheduled_task_list and scheduled_task_delete 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?

The parenthetical '(from scheduled_task_list)' tells the agent where the required id comes from, which establishes the intended call sequence (list first, then get). It stops short of explicit when-not-to-use guidance or stating the alternative for fetching multiple tasks.

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/openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: the returned field set, the presence/absence of taskExecutorResponse, and the non-obvious fact that trigger time/condition is not a separate field and must be inferred from description.

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 resource definition, followed by the creation workflow and the return-value caveat. No filler, and each sentence carries distinct 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?

With no output schema, the description compensates by enumerating the returned fields and warning that the trigger time/condition is not a discrete field. Combined with the create-via-ask_anon workflow, an agent has everything needed to call and interpret this 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 tool takes zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument, list-everything call and adds no misleading parameter expectations.

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

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

States a specific verb (list) and resource (user scheduled tasks), then defines what that resource actually is: automations created through Anon that run at a scheduled time or on a price condition. This clearly separates it from scheduled_task_get and scheduled_task_delete among 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 states there is no create/update tool and routes the agent to ask_anon for creation, then tells the agent to use this tool to confirm existence. That is a concrete when-to-use plus an alternative, which is exactly what usage guidance should do.

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 destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description reinforces this concretely ('moves real funds and cannot be undone') and adds an operational constraint (do not guess or round values) that annotations cannot express. It stops short of noting the non-idempotency implication of retrying a send, so it is not a full 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 action and its irreversibility, then the invocation conditions, then the return shape. No filler and no 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 6-parameter destructive transfer with full schema coverage and an output schema, the description supplies everything the schema and annotations cannot: irreversibility, the no-guessing policy, and the confirm-with-user fallback. Return values need not be explained since an output schema exists.

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 and the schema already documents each field including units and address resolution. The description adds genuine parameter-level value by forbidding inference, rounding, or topping up of amount/recipient/asset/chain, which is a semantic constraint the schema does not encode.

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 (send a token, ERC-20/SPL/jetton, from a user wallet to another address), and the token scope implicitly distinguishes it from the sibling transfer_native. An agent can select between the two transfer tools without opening either schema.

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

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

Gives explicit when-to-use conditions ('only when the user explicitly asked to send this exact amount of this asset from this wallet to this recipient on this network') plus a when-not-to-act rule ('never infer, round or top up any of these values') and a fallback ('if anything is missing or ambiguous, ask the user'). This is exactly the routing and guardrail guidance an agent needs for a fund-moving tool.

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 destructiveHint=true and idempotentHint=false. The description adds useful human-legible context beyond them: it moves real funds, cannot be undone, and returns the tx hash plus explorer link; the 'cannot be undone' point partially overlaps the destructive hint but the fund-movement warning is valuable.

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, followed by the safety constraint and the return contract; each sentence contributes to correct invocation. Slightly verbose but with no wasted 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 safety-critical transfer with full schema coverage and an output schema, the description covers intent, risk, and call preconditions. The one remaining gap is not naming the alternative tool for non-native asset transfers, which is minor given the explicit 'native coin' framing.

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 all five parameters (including the allBalance flag and amount units) are fully documented in the schema. The description adds no parameter-specific syntax or format beyond what the schema already provides, 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 (send) and resource (native coin of a network) with scope (wallet to address), illustrated by examples (ETH, S, SOL, TON). It implicitly distinguishes itself from transfer_asset via 'native coin', but never names that sibling, so sibling differentiation is left to inference.

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 conditions: call only when the user asked for this exact amount/asset/wallet/recipient/network, never infer/round/top up, and ask instead of guessing when ambiguous. Strong positive and negative guidance, but it does not route the agent to transfer_asset for token transfers, which is the key alternative.

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 openWorldHint=false, so the safety profile is covered. The description nonetheless adds real behavioral context beyond them: the existence of archived (soft-deleted) wallets that should be skipped, and the fact that returned addresses are reused by ask_anon and portfolio_*. It stops short of stating permissions or matching fuzziness.

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 resource and returned fields, then usage, then cross-tool linkage. Every clause carries an actionable constraint (one-per-type cap, skip archived) with 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 no-parameter, no-output-schema read tool the description is nearly self-sufficient: output fields, selection rules and downstream consumers are all covered. Only minor gaps remain, such as whether an empty wallet list is possible or how matches behave when a name is ambiguous.

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?

Zero parameters, so the baseline is 4 per the rubric. The description compensates usefully by clarifying the shape of the returned records (type values such as evm, solana, ton) rather than leaving the fields unnamed.

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) plus resource (user wallets in Hey Anon) and enumerates exactly what each entry contains: display name, type, address, labels, archived flag. Nothing about it could be confused with siblings like address_book_list or portfolio_*.

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

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

Gives explicit when-to-use (call before ask_anon to pick addresses), the selection rule (at most one per type), the matching heuristic (display name, label or address) and an exclusion (skip archived wallets). It also routes the agent to the related portfolio_* tools, so alternatives are named rather than 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so 'Read-only' is a repeat. The description earns credit for disclosing that this is an authenticated call that exercises the API key — a behavioral trait the annotations do not express — and for previewing what the response contains.

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 purpose before the field list and the usage note. The field enumeration partially duplicates the output schema, but it is brief and helps an agent recognize the tool's value at a glance.

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

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

With an output schema present the description need not detail return values, yet it does so concisely; combined with the auth note and the ping contrast, an agent has everything needed to call it. It stops short of mentioning failure behavior on an invalid key, 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. It correctly stays silent on 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?

States a specific verb (check) and resource (which Hey Anon account the connection's API key belongs to), then enumerates the exact returned identity fields. An agent can distinguish this from siblings like login_status or ping purely from this sentence.

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

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

Gives an explicit use case (verify a login) and pre-empts the obvious wrong choice by naming the sibling alternative: 'an authenticated call; ping alone does not prove the key works.' That is a when-to-use plus a when-not-to-use in one clause.

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