recon-crypto-mcp
Server Quality Checklist
Latest release: v0.14.4
- Disambiguation4/5
Tools are generally well-distinguished by protocol and operation, but the sheer number (189) creates potential confusion among similar-named tools like get_btc_balance vs get_btc_account_balance. Detailed descriptions mitigate this, but an agent may still mis-select in edge cases.
Naming Consistency5/5All tool names follow a consistent verb_noun snake_case pattern (e.g., get_btc_balance, prepare_aave_supply). No mixing of conventions or vague verbs observed.
Tool Count1/5189 tools is far beyond the typical MCP server scope. This number overwhelms agents and suggests lack of focus. A more reasonable count for this domain would be under 50.
Completeness5/5The tool set covers an exhaustive range of crypto operations across multiple chains (EVM, Solana, TRON, Bitcoin, Litecoin), including DeFi, staking, swaps, NFTs, portfolio, and security. No obvious gaps for the intended scope.
Average 4.5/5 across 189 of 189 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 48 of 73 community issues answered or closed in the last 6 months
- 60 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Business Source License 1.1.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true. The description states it builds an unsigned transaction, implying no on-chain changes, which conflicts with destructiveHint. It does not clarify that the output must be signed and broadcast separately, leaving the agent uninformed about the full workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff, efficiently conveying core purpose. However, the structure could benefit from listing parameters or output details given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description omits what the tool returns (e.g., unsigned transaction hex) and how to proceed (signing/sending). Given three required parameters and four total, the description leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only reinforces the amount parameter's human-readable format, but schema coverage is only 25% (only amount has schema description). It fails to explain wallet, to, or chain parameters, and incorrectly limits chains to Ethereum/Arbitrum while schema includes Polygon, Base, Optimism.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned native-coin send transaction, giving examples like ETH on Ethereum/Arbitrum. This distinguishes from token send or swap tools. However, it only mentions two chains while the schema includes five, slightly narrowing scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives minimal guidance: mentions passing a human-readable amount but does not explain when to use this tool versus alternatives like prepare_token_send or prepare_swap. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds that it returns null if no primary name is set, which is useful behavioral detail. No contradictions, but additional traits like network dependency or error handling are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that includes the action and return behavior. It is front-loaded and contains no extraneous information, though it could slightly expand on address formats without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup without output schema, the description mentions the return value (null if unset). However, it lacks context on supported networks, potential errors, and assumes the agent knows ENS mechanics. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must elaborate on the parameter. It says 'Ethereum address' but the schema allows three patterns, only one of which is Ethereum. This adds partial meaning but is inaccurate for the other formats and does not explain their purpose or validity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reverse-resolves an Ethereum address to its primary ENS name, distinguishing it from forward resolution (e.g., resolve_ens_name). However, it mentions only 'Ethereum address' while the input schema includes patterns for non-Ethereum addresses (T and base58), causing slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. It implies reverse resolution but lacks guidance on prerequisites, network context, or exclusions. The sibling `resolve_ens_name` is not mentioned, leaving the agent to infer the differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint as true; description adds that the output is an unsigned transaction and requires collateral. This provides moderate context beyond annotations, but lacks details like error conditions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences, front-loaded with the action, and no extraneous information. Efficient but could be slightly more precise about output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good schema coverage, the tool is complex (borrow transaction preparation) with no output schema. Description fails to mention the output format or that the unsigned transaction needs to be signed/sent, leaving an agent potentially underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage), so the description adds minimal value. The amount field has an example, but this is already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it builds an unsigned Morpho Blue borrow transaction, differentiating it from sibling tools like prepare_morpho_supply or prepare_morpho_repay. The prerequisite of pre-existing collateral adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the mention of required collateral is a precondition, it doesn't help an agent decide between borrow, supply, or other morpho operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat that. It adds value by specifying the exact data returned (collateral, debt, health factor, LTV, liquidation threshold) and mentions the chains (Ethereum and Arbitrum). However, it does not disclose any rate limits, error behaviors, or the effect of the optional 'chains' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key purpose and lists important details. It is efficient and avoids fluff, though a bulleted list could improve scanability. It earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-chain, multi-field positions) and absence of an output schema, the description covers the core purpose and return fields. However, it lacks details on how the 'chains' parameter interacts with the return (does querying multiple chains aggregate or separate?), default behavior, and the exact structure of the response (e.g., per-asset breakdown format). It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description should compensate. It mentions 'wallet' implicitly and 'chains' by naming example chains, but it does not explain the wallet format (0x address), that chains is an array, or that polygon/base/optimism are also valid despite the description focusing on Ethereum and Arbitrum. The description adds minimal meaning beyond the schema's pattern and enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (fetch all lending/borrowing positions), the protocol (Aave V3), and the target (wallet). It lists the returned fields (collateral, debt, health factor, LTV, liquidation threshold) and chains (Ethereum and Arbitrum), making it easy to distinguish from sibling position-fetching tools like get_compound_positions or get_kamino_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While the name and sibling context imply it is for Aave V3 positions, there is no guidance on prerequisites, when not to use it, or comparisons with other position tools. Usage is implied but not explicitly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: notes that the transaction is unsigned and that an ERC-20 approval step is included if needed. Annotations already indicate destructiveHint and non-readOnly, but description clarifies the unsigned nature and approval handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences with no filler. The main action and a key detail (approval step) are front-loaded. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal context: does not explain return value (unsigned transaction), error conditions, prerequisites, or how the approval step works. No output schema. For a tool preparing a DeFi deposit, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not explain any of the 5 parameters, despite low schema description coverage (40%). The schema has descriptions only for 'amount' and 'approvalCap'; the other three (wallet, strategy, token) remain undocumented. The description fails to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool builds an unsigned EigenLayer deposit transaction and includes an ERC-20 approve step if needed. The specific contract (StrategyManager.depositIntoStrategy) and action are named, distinguishing it from other prepare_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like prepare_aave_supply or prepare_compound_supply. Usage is implied by the EigenLayer context, but no when-to or when-not-to instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show destructiveHint=true and idempotentHint=true, but the description adds critical behavioral context: stable rate borrows revert on production markets, and the borrower must have collateral. This goes beyond annotations by disclosing a deprecated functionality that could cause failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first explains the core action and a critical caveat, the second adds a prerequisite. No redundant information, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not specify the output format (e.g., unsigned transaction payload details) and has low parameter coverage. However, for a transaction preparation tool with clear sibling context, it is adequately complete for basic usage, though missing output description is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only the 'amount' parameter has a description). The description repeats the 'max' option already in the schema but does not explain 'wallet', 'asset', or 'chain' parameters beyond what the schema provides. This fails to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned Aave V3 borrow transaction, specifies variable rate, and notes stable rate is deprecated. This distinguishes it from sibling tools like prepare_aave_repay or prepare_aave_supply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (sufficient collateral) but does not explicitly state when to use this tool versus other borrow preparation tools (e.g., prepare_compound_borrow) or provide criteria for exclusion. Usage context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations: it explains that if an ERC-20 approve() is required, it is returned as the outer transaction with the supply in `.next`. This behavior is not covered by annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no extraneous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool (Compound V3 supply with possible approval chaining), the description covers the main purpose and approval handling. Lacks details on return shape (only mentions `.next`), but output schema is absent so not required. Adequate for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema's parameter descriptions. The mention of approval behavior indirectly relates to the approvalCap parameter, but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Build', the resource 'unsigned Compound V3 supply transaction', and the scope 'base token or collateral'. It also distinguishes from sibling tools like prepare_compound_borrow, prepare_compound_repay, prepare_compound_withdraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states what it does without specifying context, prerequisites, or exclusions. Siblings include many prepare_* tools, but no comparison or selection criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true and idempotentHint=true, but description adds that the transaction is unsigned and includes an optional approve step, which is important behavioral context. However, it does not detail the return value or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action without any fluff. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite moderate complexity, the description lacks information about the return value (no output schema) and when the approve step is needed. This leaves the agent with incomplete context for using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, and the description adds no additional parameter details beyond what the schema provides. The schema already explains amountStETH and approvalCap well, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned Lido withdrawal request transaction, specifying the underlying function (requestWithdrawals) and mentioning the approve step. This distinguishes it from other Lido tools like prepare_lido_stake and prepare_lido_unwrap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for unstaking Lido stETH but does not explicitly state when to use it versus alternatives like prepare_rocketpool_unstake or when not to use it. No exclusions or context for sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool modifies state by pinning the handle, but the annotation readOnlyHint=true contradicts this. Per the scoring rule, a contradiction earns a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured, front-loading the purpose and providing necessary context without extraneous content. Slightly verbose but each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully covers return values (UnsignedSolanaTx, messageBase64, ledger Message Hash, CHECKS PERFORMED), error handling, and workflow dependencies. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about re-callability and workflow, but the parameter description in the schema already conveys the necessary meaning. No significant extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finalizes a prepared Solana transaction for signing, specifies the actions (fetching blockhash, serializing, computing hash), and distinguishes it from sibling tools like prepare_solana_* and send_transaction by positioning it as an intermediate step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the tool MUST be called between prepare_solana_* and send_transaction, explains why due to blockhash expiry, and notes that it is re-callable. Also warns that send_transaction will error if called without a prior preview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description reinforces that it 'surfaces data; it does NOT pick.' Adds context about the meaning of 'no dangerous functions' and agent behavior refusal. 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long and includes repetitive warnings and issue references. While informative, it could be more concise. Essential information is present but padded with redundant instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description does not explain the output format or structure. For a complex analysis tool, agents need to know what findings are returned. Parameter semantics are also incomplete, leaving gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. The description only vaguely alludes to 'a given contract' but does not explain the address or chain parameters. Missing explicit descriptions of parameter purpose, formats, or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it checks Etherscan verification, proxy patterns, and dangerous admin functions. Distinguishes from unrelated tools by explicitly stating what it does NOT measure (token upside, price direction, investment merit). Provides a specific SCOPE: 'protocol/contract safety only'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for due diligence on contract safety. Instructs agents not to use clean security reports as token-pick validation and to refuse speculative prompts. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Read-only — no on-chain side effect, no signing', but annotations have readOnlyHint=false, which contradicts this. Per guidelines, a contradiction scores 1. Additional behavioral info like redaction scan and validation rules is useful but undermined by the contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured, with the main purpose upfront followed by specifics on usage, validation behavior, and safety. Every sentence adds information, and it avoids unnecessary repetition. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully explains the return value ('validated SharedStrategy for read-only inspection') and covers key aspects: input types, redaction scanning, strict shape validation with forward-compatibility, and the read-only nature. This provides sufficient context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 100%, the baseline is 3. The description adds value by explaining how to pass the JSON (stringified or parsed object) and referencing the output of share_strategy. This goes beyond the schema's description, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Parse and validate a shared-strategy JSON produced by share_strategy'. It specifies the resource (shared-strategy JSON), the action (parse and validate), and distinguishes it from the sibling tool 'share_strategy' which presumably exports the JSON.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: when you have a shared-strategy JSON to validate and inspect. It clarifies that it works for both someone else's strategy or one the user generated earlier, and mentions return for read-only inspection. However, it does not explicitly state when not to use it or mention alternatives beyond share_strategy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses many behavioral details (cost, durable nonce, blind-sign, refusal on repeat), but it contradicts the annotation idempotentHint=true. The description states it refuses if userMetadata already exists, which means repeating the call with the same wallet will fail, thus it is not idempotent. This contradiction forces a score of 1 per rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is four sentences, dense with information but not verbose. Key points are front-loaded (first-time setup, creates accounts, one-time). A minor improvement could be splitting the cost details to improve readability, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers prerequisites, costs, refusal condition, and security warnings (durable nonce, blind-sign). It does not explicitly state that the tool returns a transaction, but this is implied by the 'prepare' pattern and sibling tools. Minor gap but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context beyond the schema: it explains that the wallet funds specific accounts with rent estimates (~0.014 SOL, ~0.012 SOL, ~0.002 SOL) and requires an initialized durable-nonce account. This helps the agent understand the parameter's implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is for first-time Kamino setup, creates specific accounts (user lookup table, userMetadata PDA, obligation PDA), and is a one-time prerequisite. It distinguishes itself from sibling tools like prepare_kamino_supply by explicitly calling itself a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'ONE-TIME — required prerequisite before prepare_kamino_supply / borrow / withdraw / repay' and 'Refuses if userMetadata already exists (use the supply tool directly).' It also warns about durable nonce requirement and blind-signing, providing clear when-to-use and when-to-avoid guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals that the output is an unsigned transaction and specifies the contract interaction (stETH.submit). Annotations indicate destructive (writes) and idempotent, which the description aligns with. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 22 words. The first sentence states the core action, the second clarifies the value field. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, and the description does not describe the return value format or structure. For an unsigned transaction builder, the agent may need to know the transaction object shape. The description is sufficient but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 50% coverage (amountEth has a description; wallet lacks one). The description adds that amountEth is human-readable (but schema already states that). No new semantics for wallet beyond the pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool's action: building an unsigned Lido stake transaction that wraps ETH into stETH via stETH.submit. This clearly distinguishes it from sibling tools like prepare_lido_unstake or prepare_lido_unwrap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for staking ETH via Lido, but it does not provide explicit guidance on when to use it versus alternatives (e.g., other staking protocols). No when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark it as destructive and idempotent. Description adds that it includes an approval step if needed, and explains the 1:1 share ratio, which informs about state changes and safety. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential. First states core action and key properties, second covers the approval step. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description omits return value (presumably an unsigned transaction object). For a builder tool, mention of output type would help. Annotations provide some behavioral context but completeness is medium.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 2 of 3 parameters with descriptions (amountStETH, approvalCap). Description adds no extra parameter info. Wallet parameter lacks description but pattern is clear. With 67% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool prepares an unsigned wstETH.wrap transaction converting stETH to wstETH, with key details (1:1 share, no DEX fee, approval step). Distinct from siblings like prepare_lido_stake/unstake/unwrap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: when needing to convert stETH to wstETH. No explicit comparison to siblings (e.g., when to use prepare_lido_wrap vs prepare_lido_unwrap) or when-not-to-use. Lacks alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the transaction includes an approval step if needed, adding context beyond the annotations (readOnlyHint=false, destructiveHint=true). It also reinforces the idempotent nature noted in annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear statements. It front-loads the main purpose, then adds relevant details. Every sentence provides value, though the first sentence could be more specific to differentiate from other prepare tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 3 required) and full schema coverage, the description is adequate. It explains the approval step and amount limitation but does not describe the output (unsigned transaction) or prerequisites (e.g., wallet connection, chain). Without an output schema, some guidance on expected return would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% description coverage, the tool description explicitly states 'max is not supported', which directly contradicts the schema's description for the 'amount' parameter that says 'Pass max for full-balance withdraw/repay'. This inconsistency harms clarity and reduces the value added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Build an unsigned Morpho Blue repay transaction' and includes a key constraint ('Explicit amount only — max is not supported'). It distinguishes itself from sibling tools like prepare_morpho_borrow and prepare_morpho_supply by explicitly naming 'repay'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool (for repay actions) and highlights a critical limitation ('max is not supported'). However, it does not explicitly contrast with alternative tools (e.g., when to use prepare_morpho_borrow instead), though the sibling tool names make the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and safe traits. The description adds detail on return sections (e.g., mSolPrice, activation status) but does not reveal new behavioral traits beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loaded with 'READ-ONLY', and efficiently covers three sections. However, it could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly explains the three return sections with details (mSolPrice, activation status). It also references the parallel EVM tool, making it complete for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a detailed description of the 'wallet' parameter, including the pattern and what it returns. The tool description adds little new semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it enumerates Solana staking positions, listing specific protocols (Marinade mSOL, Jito jitoSOL) and native staking. It also notes it is parallel to EVM's get_staking_positions, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context as a single full-view tool, with mention of underlying module functions for individual sections. It implicitly distinguishes from EVM staking tools via 'Parallel to EVM's get_staking_positions', but lacks explicit 'when not to use' or direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: the estimation nature, use of current APR as proxy, and explicit warning that it is not an on-chain query. This adds behavioral insight beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no redundant words. Every sentence adds value: the first defines what and period, the second clarifies limitation. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey behavior and limitations. It does so by explaining the estimation method and what it is not. It could optionally mention the return format (e.g., a numeric value), but the current completeness is sufficient for a simple estimation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions (wallet regex, period enum/default). Schema coverage is 100%, so baseline is 3. The description mentions period options and APR proxy, providing slight context about calculation basis but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates staking rewards over specified periods using current APR as a proxy. It explicitly distinguishes itself as an estimate, not an on-chain query, which clarifies its scope and differentiates it from tools like get_staking_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for estimating rewards based on APR) and what it is not (on-chain query). However, it does not address when to avoid it in favor of siblings like estimate_staking_yield or get_staking_positions, leaving some ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'no approval needed' and 'burns wstETH from caller's balance' beyond annotations. Annotations already indicate destructive and idempotent, but description enriches behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, efficient delivery of purpose and key behavioral trait.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description covers purpose, mechanism, and safety (no approval). Missing details on stETH destination, but sufficient for a build-transaction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 50% coverage; amountWstETH is well-described, wallet has no description. Overall description does not add parameter details beyond schema. Minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds an unsigned wstETH.unwrap transaction converting wstETH to stETH. Specific verb and resource differentiate from siblings like prepare_lido_wrap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for converting wstETH to stETH, but lacks explicit guidance on when to use vs alternatives like prepare_lido_unstake. No direct mention of exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true (state mutation) and readOnlyHint=false, so the agent knows this is a write operation. The description adds that it includes an 'approve step if needed', which is a key behavioral detail not in annotations. It could detail more (e.g., what gets destroyed), but the annotation safety profile is already clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the core action, second adds the critical 'approve step' detail. No wasted words, front-loaded with key purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction-building tool with 100% schema coverage and annotations, the description is sufficient. It explains what the tool does and a key behavior (approve step). However, it does not clarify the difference between 'supplyCollateral' and 'supply' (which may supply loan assets), which could cause confusion given many similar sibling tools. Still, the name and description together are adequate for an agent familiar with Morpho Blue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters well with human-readable descriptions. The tool description does not add new meaning beyond naming the action; it mentions 'human-readable decimal amount' and 'approve step' but these are already covered in schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned Morpho Blue supplyCollateral transaction that adds collateral to a market. It uses specific verbs ('build', 'adds') and identifies the resource ('Morpho Blue supplyCollateral transaction'). This differentiates it from sibling tools like prepare_morpho_supply (which likely supplies loan tokens).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for collateral supply on Morpho Blue but does not explicitly state when to use this versus siblings like prepare_morpho_supply. There is no guidance on prerequisites or fallback tools. The usage context is implied by the tool name and description but lacks explicit 'when-not' or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by explicitly stating the tool 'surfaces data; it does NOT pick' and describing the types of holders it classifies (EOA, Gnosis Safe multisig, TimelockController). This goes beyond 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but verbose, including an issue reference ('Issue #599') and repeated emphasis on what the tool does not do. While well-structured with clear sections, it could be more concise without losing core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's security focus, the description covers purpose, scope, behavioral constraints, and usage guidelines adequately. However, it lacks details about the return format or output structure, which would be helpful for an agent to process results. No output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage; the description does not elaborate on the parameters beyond what is in the schema (address pattern, chain enum). The agent must rely solely on the schema definitions, which are minimal. The description adds no new semantic information about the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Enumerate privileged roles' and specifies the resource (contract roles like Ownable.owner, AccessControl hints) and classification of holders. It distinguishes itself from sibling tools like 'check_contract_security' by focusing specifically on governance posture and explicitly stating what it does not measure (token upside, price direction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance. It states the tool is for due diligence, not for picking tokens, and instructs the agent to refuse speculative-pick prompts. It also clarifies the interpretation of results ('safety floor, NOT an upside signal').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds meaningful behavioral context: multi-address nature, per-address error handling resulting in 'errored' entries, and output shape mirroring get_btc_balance. No contradictions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: stating the operation and limits, explaining error behavior, and referencing sibling output for output shape. No redundant or extraneous information. The purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by referencing get_btc_balance's output shape. The single parameter is fully described in the schema. Given the tool's simplicity and the coverage from schema and annotations, the description is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with descriptive text for the parameter and its items. The description reinforces the per-address error handling already in the schema, and adds context about output similarity to get_btc_balance, but does not significantly enhance meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a READ-ONLY multi-address Bitcoin balance fetch for 1-20 addresses, with a specific verb (fetch), resource (Bitcoin balances), and scope. It distinguishes itself from siblings like get_btc_balance by specifying multi-address capability and per-address error handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives such as get_btc_balance or get_btc_account_balance. It mentions error handling but does not provide conditions like 'use when needing multiple addresses' or 'for single address use get_btc_balance'. The purpose is clear but the usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description goes beyond by stating 'no device touch' and describing the content of each UTXO (witnessScript + cosigner pubkeys), which adds behavioral context about the output. No contradictions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loaded with the primary purpose. It is minimal but includes necessary context. No wasted words, though it could be slightly more compact by merging the last two sentences. Still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides information about the return content (witnessScript + cosigner pubkeys). It covers the tool's role (inspection vs. tx preparation) and safety ('no device touch'). For a straightforward read-only tool with two parameters, this is adequate but could include more about gapLimit defaults or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%. The description adds value for walletName by linking it to the input pool for prepare_btc_multisig_send. For gapLimit, it only references 'same gap-limit walk as get_btc_multisig_balance,' which does not explain the parameter's meaning or constraints. The description partially compensates for schema gaps but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the UTXO set for a registered multi-sig wallet, using same gap-limit logic as get_btc_multisig_balance. It explicitly differentiates from prepare_btc_multisig_send by noting internal usage and direct exposure for inspection. Additionally, 'no device touch' clarifies it's a read-only operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool: to 'inspect the spendable set without preparing a tx.' It also notes the tool is used internally by prepare_btc_multisig_send, providing context for alternatives. However, it does not explicitly list when not to use it or edge cases, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds value by listing returned fields (token pair, amounts, fee tier, etc.), which are not in the schema. No contradictions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists outputs. Front-loaded, no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains what is returned. However, it does not mention that wallet is an Ethereum address or that chains is optional. Still reasonably complete for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It only mentions 'for a wallet' but does not describe the wallet format or the chains enum. The schema has pattern and enum, but no additional semantics in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches all Uniswap V3 liquidity-provider positions for a wallet, with specific verb 'Fetch' and resource 'Uniswap V3 liquidity-provider positions'. Distinguishes from sibling tools like get_compound_positions by naming the protocol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for Uniswap V3 positions, but does not explicitly state when not to use or suggest alternatives. However, the protocol name in the description provides clear context for when to select this tool among similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavioral traits beyond annotations: multi-chain fan-out with error isolation via Promise.allSettled, the meaning of totalFloorUsd as an upper-bound caveat, and per-collection aggregation. Annotations already declare read-only, so the description adds value on error handling and value interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose, including issue numbers, follow-ups, and deferred features that are not essential for tool usage. Key information is front-loaded but buried in technical details. It could be significantly shortened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-chain, multiple parameters, no output schema), the description is fairly complete. It covers the output shape (per-collection rows, coverage flags, notes), error behavior, and parameter constraints. Missing explicit output field list, but still highly informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds substantial context: explains the aggregation logic, optional filters (minFloorEth, collections), and their effects. It also mentions sources (Reservoir, Helius) and how filters behave across chains. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists NFT collections a wallet owns across EVM chains and/or Solana, with floor prices and total floor value. It uses a specific verb (List) and resource (NFT collections), distinguishing it from siblings like get_nft_collection and get_nft_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: for portfolio overview across multiple chains. It mentions required parameters (at least one wallet), warns about limitations (Solana floor pricing deferred), and notes that signing actions are handled separately. It could explicitly compare to similar tools, but the context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and idempotentHint=true, and the description adds 'Read-only — no signing, no broadcast.' It also details suspectedPoisoning field, agent behavior instructions, and chain-specific parameter handling, going far beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose (multiple paragraphs) with redundant phrasing and embedded agent behavior instructions that could be separated. It front-loads purpose but includes unnecessary detail, reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage and no output schema, the description covers chain support, merged data types, poisoning detection, and agent behavior. However, parameter semantics are incomplete, and output structure is not described, leaving some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only partially compensates: it explains limit (default 25, max 50), includeInternal implications, and chain enum via backend providers. But wallet, includeExternal, includeTokenTransfers, startTimestamp, and endTimestamp are not explained beyond the schema patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a wallet's recent on-chain transaction history merged across external, token transfers, and internal txs on a single chain. It specifies chains and features, differentiating it from sibling tools by its merged nature and comprehensive scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to answer what did I do last week? etc.' and mentions chain-specific behavior (includeInternal ignored on TRON/Solana). However, it does not explicitly state when not to use it or provide alternatives to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is 'Read-only — no signing, no broadcast,' but annotations set `readOnlyHint: false`, indicating it may modify state. This is a direct contradiction, so transparency scores 1 as per rules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of 6 sentences, but each sentence adds value. It is front-loaded with the main action. Could be slightly more concise, but overall efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description details the return fields (`wallets, scope, name, issuedAt, expiresAt, id`), explains the intended usage pattern, error behavior, and storage characteristics. This is complete for a decoding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only specifies a string parameter without description. The description adds crucial semantic information: the token can be a raw `vp1.…` string or a URL with `?t=` or `#t=` parameter. This compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: decoding a `vp1.…` read-only share token into a wallet bundle. It specifies input formats (raw token or URL with parameter) and output structure. It distinguishes from siblings like `generate_readonly_link` and subsequent `get_*` tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool (when a read-only token is received) and what to do after (use standard portfolio reads). It also covers error handling for expired tokens and notes that the tool is read-only and stores nothing. This provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is destructive and idempotent. The description adds the key behavior of returning a potentially nested transaction structure, which goes beyond annotations. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes all essential behavioral nuance without superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a potential two-step transaction, the description covers the core pattern. It does not detail the return structure beyond `.next`, but combined with annotations (destructive, idempotent), it provides adequate context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%, requiring the description to add meaning to parameters. However, the description does not explain wallet, chain, or asset fields, and only mentions 'ERC-20 approve' indirectly. The 'amount' and 'approvalCap' descriptions are in the schema but not reinforced here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Build an unsigned Aave V3 supply transaction' which is a specific verb+resource combination. It clearly distinguishes from sibling tools like prepare_aave_borrow and prepare_aave_withdraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that if an approval is required, it is returned as the outer transaction with the supply embedded in `.next`, and that both must be signed. This provides practical guidance but does not explicitly state when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by detailing implicit consent, threshold check, fallback to Safe Transaction Service, and return value (UnsignedTx). 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but could be more structured; front-loaded purpose but the paragraph mixes multiple concepts without clear separation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Very complete: covers return format, failure mode, ETH flow, and fallback behavior. No output schema, but the description compensates well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description partially explains executor role and mentions other params implicitly, but does not individually document each parameter or provide format details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an execTransaction UnsignedTx for Safe multisig execution, distinguishing it from sibling propose/approve tools by mentioning the flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (after signatures via propose/approve) and implicit consent for executor, but does not explicitly list exclusions or compare to other siblings like submit_safe_tx_signature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool builds an unsigned transaction and returns a preview + opaque handle, and that signing/broadcasting is handled by send_transaction. It also mentions hardware dependency (Ledger via USB HID). Annotations indicate destructive and idempotent, which aligns with creating a transaction that can be recreated. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loads the core function. It avoids unnecessary details while still covering essential workflow steps. Slightly repetitive mention of TronGrid could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (preview + handle) and the required follow-up (send_transaction). It also covers the prerequisite (pair_ledger_tron). This is complete for a preparation tool within a multi-step workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters (from, to, amount). The description adds no additional detail beyond what the schema states, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned TRON native TRX send transaction via TronGrid's API, and distinguishes from sibling tools like prepare_tron_token_send by specifying 'native TRX send'. It also explains the output (preview + handle) and the next step (use send_transaction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (for sending TRX) and prerequisites (run pair_ledger_tron first). It also directs the user to forward the handle via send_transaction. It lacks explicit exclusion of alternatives, but the sibling list implies other tools for token sends.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behaviors beyond annotations: on-chain verification before posting, auto-detection of proposeTransaction vs confirmTransaction, and return of a Safe UI deep-link. It adds depth to the destructiveHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the key action and context. While slightly long, each sentence adds value. Minor redundancy could be trimmed, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the sequence, preconditions, and return value, but leaves gaps: parameter meanings are unclear, especially the absence of a signature parameter. The relationship with siblings is partially explained but could be more precise. Given the complexity and lack of output schema, more detail on parameters is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the description fails to explain the role of each parameter. Notably, the 'signature' is not a parameter, while the tool claims to 'post the signature.' The description does not clarify how the signature is obtained or what the signer, safeAddress, chain, and safeTxHash represent in this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: after the on-chain approveHash transaction is mined, post the signature to the Safe Transaction Service. It specifies the action and distinguishes it from siblings like prepare_safe_tx_* by detailing the follow-up step and auto-detection behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: use after the approveHash tx is mined. It also describes preconditions (on-chain approval must exist) and refusal behavior. While it does not explicitly list alternatives, the context clearly indicates it is a post-approval step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds that it is read-only and requires RPC configuration, and it lists specific data fields beyond what annotations convey. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: it front-loads 'READ-ONLY', lists outputs, states RPC requirement, provides use case, and references issues. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers purpose, data fields, usage context, and prerequisites. Minor omissions like error handling or valid block assumptions are acceptable given the clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a detailed description of the hashOrHeight parameter. The tool description does not add additional parameter information beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that this tool provides bitcoind getblockstats output including fee distribution percentiles, tx count, block size, and total fees. It distinguishes itself from Esplora by noting that Esplora lacks fee percentiles, and it clearly targets fee-market anomaly detection and baselines for mempool_anomaly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is RPC-only and requires BITCOIN_RPC_URL configured, and that it is used for fee percentiles not available via Esplora. It provides context for when to use this tool (spotting fee anomalies) but does not explicitly name an alternative tool for simpler queries like block size/tx count.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds valuable context: derivation from cosigner xpubs, BIP-32 chain walking, gap-limit behavior, and the limitation to P2WSH (Phase 3). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the core purpose and then efficiently detail the derivation method, chain walking, and limitation. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (BIP-32, gap limit, P2WSH limitation, no output schema), the description covers essential behavioral aspects: it communicates what is returned (aggregate + per-address breakdown) and how addresses are derived. Still, the lack of explicit return format or error cases is acceptable for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds meaninful detail beyond schema: walletName is linked to `register_btc_multisig_wallet`, gapLimit explains default 20 with BIP-44 context and cap rationale. The per-address breakdown detail is implied but not specified in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Watch-only balance read for a registered multi-sig wallet', clearly stating the verb, resource, and scope. It distinguishes itself from sibling tools like `get_btc_balance` (single-sig) and `get_btc_multisig_utxos` (UTXOs) by focusing on aggregate balance with per-address breakdown from derived chains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick balance checks ('No device touch') and notes a P2WSH-only limitation, but does not explicitly state when to use this tool over alternatives like `get_btc_multisig_utxos` or `get_btc_balance`. No mention of prerequisites beyond registration or contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: the data source (Esplora indexer), the output details (confirmed+mempool litoshis, LTC decimal), and the fact that format validation is the only check. Annotations already indicate read-only and idempotent, so the description enhances transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: first states purpose and source, second details output, third notes address formats and limitations. No extraneous information, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple balance retrieval with one parameter, the description is fairly complete. It could explicitly mention the return JSON structure (field names), but the lack of an output schema means the agent must infer. Still, it provides necessary context for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the address parameter, detailing format and limitations. The tool description does not add meaningful semantics beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the on-chain balance for a Litecoin mainnet address, specifying the data source (Esplora indexer) and output components (confirmed+mempool litoshis, LTC decimal). It distinguishes from siblings by focusing on Litecoin and listing specific address formats, and notes limitations (mainnet only, no testnet/MWEB).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use: for getting Litecoin balance, and it notes that the read path only validates format, so it does not confirm address usage. However, it does not explicitly compare to other get_ltc_* tools or provide alternative scenarios, but the context of sibling tools (e.g., get_ltc_blocks_recent) makes it clear this is for balances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds configuration requirement and mirror relationship. No contradictions; it extends annotation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. First sentence states purpose and read-only nature, second adds mirror and config requirement. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explicit return value description, but 'litecoind getblockstats output' is a known RPC format, providing enough context for an agent familiar with the ecosystem. Issue references are extra.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and schema description explains hashOrHeight parameter well. Description adds no new semantic detail beyond 'mirror of BTC version', which is marginal. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a read-only tool for litecoind getblockstats output. Explicitly identifies as mirror of get_btc_block_stats for LTC, distinguishing it from its sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States prerequisite (LITECOIN_RPC_URL configured) and implies usage for LTC block stats. Does not explicitly state when not to use, but the mirror reference provides guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true. The description adds value by explaining multi-chain result merging, timestamp sorting, a cap at `limit`, and the data source (Reservoir API). 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, followed by key behavioral details and a sibling reference. No wasted words; every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 params, strong annotations), the description covers source, event types, merging, sorting, cap, EVM limitation, and relations to sibling. Lacks explicit return structure but references `get_transaction_history`'s shape, which compensates. Well-rounded for a read-only query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 2 of 3 parameters (chains, limit) completely, and the description mostly echoes those details. For the wallet parameter, the description only says 'EVM wallet' but schema pattern already implies that. No new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('get', 'list') and nouns ('NFT activity', 'mints, sales, transfers, listings, bids, cancels') and clearly identifies the resource (wallet address across EVM chains). It distinguishes itself from the sibling `get_transaction_history` by explicitly noting it is scoped to NFT-relevant events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it returns NFT-specific activity across EVM chains, mirrors `get_transaction_history`, and notes EVM-only with Solana deferred. It implies when to use (for NFT events) and when not (for non-EVM chains), but does not give explicit 'when not to use' or list alternatives beyond the one sibling mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations, such as the multi-step transaction structure (approve as outer tx, repay as .next) and the special 'max' amount. Annotations already indicate mutation and destructiveness, so the description complements them well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that efficiently convey the core purpose and a key behavioral detail. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior (repay, optional approve, 'max' amount) but lacks explanation of the return format or what happens when no approve is needed. Given the complexity of a multi-step DeFi transaction, it is reasonably complete for the typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%, and the description adds value for the `amount` parameter (explaining 'max' usage) and indirectly for `approvalCap` via the approve discussion. However, it does not elaborate on `wallet`, `chain`, or `asset` beyond what the schema provides, resulting in only moderate added parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Build an unsigned Aave V3 repay transaction') with specific verb and resource, distinguishing it from sibling tools like prepare_aave_borrow or prepare_aave_supply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for repaying Aave V3 debt via the name and action, but does not explicitly state when to use it over alternatives or when not to use it. It provides context on handling approvals but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true (modifies state) and idempotentHint=true. The description adds that it builds an unsigned transaction, implying no immediate effect. It doesn't elaborate on any side effects or authorization needs, but the safety profile is adequately covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with zero wasted words. It delivers the core purpose and a key usage tip immediately. No unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations describing its safety profile, the description covers essential behavioral aspects. It lacks details on the output format or typical flow, but for a transaction preparation tool, the provided information is generally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers parameters, but only 'amount' has a description. The description adds meaningful guidance by explaining the 'max' value for amount, which is not obvious from the schema alone. For other parameters, the schema provides enough via patterns and enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned Aave V3 withdraw transaction, which is specific to withdrawing. It also highlights the special 'max' amount option. Among sibling tools like prepare_aave_borrow or prepare_aave_supply, this is distinctly different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (for withdrawing from Aave) and provides a usage tip for 'max'. However, it does not explicitly contrast with other Aave operations or mention prerequisites. The context is clear but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint and idempotentHint, which align with building an unsigned withdraw transaction. The description adds that it builds an unsigned transaction (not executing), and the 'max' tip. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second gives a specific usage instruction. No redundant words, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a prepare tool with well-documented parameters, the description is adequate. It could optionally mention the output (unsigned transaction) or prerequisites (market address), but given the annotations and schema, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 5 parameters. The description adds the 'amount: max' usage hint, which is helpful but already present in the parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned Compound V3 withdraw transaction, with a specific verb 'Build' and resource. It distinguishes from siblings like prepare_compound_supply by specifying 'withdraw'. The title annotation confirms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: used for Compound V3 withdrawals, with a special tip for 'max' amount. It does not explicitly state when not to use or list alternatives, but the context is sufficient for an agent to select appropriately among the many prepare tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and idempotentHint=true. The description adds valuable behavioral details: the refusal on no debt, the clamping behavior to prevent over-repay loss, and the durable nonce requirement. This goes beyond what annotations provide, though it lacks permission requirements or return value details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three clear sentences with no superfluous text. The purpose is front-loaded, followed by error handling, clamping behavior, and a requirement note. Every sentence serves a distinct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool simplicity (3 params, no output schema) and the presence of many sibling tools, the description adequately covers purpose, error cases, behavioral quirks, and a requirement. It does not mention the return value (expected transaction object), but that is a common pattern for 'prepare' tools and not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline parameter info. The description adds context: 'wallet must have debt', 'mint' is the reserve, and 'amount' is human-readable with clamping behavior explained. This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Build' and the resource 'Kamino repay tx — pays down outstanding debt in the named reserve.' This directly distinguishes it from sibling tools like prepare_kamino_supply, prepare_kamino_borrow, etc., by specifying the action and the protocol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by stating that refusing occurs if the wallet has no debt and that over-repaying is safe. It also notes the requirement for a durable nonce and blind-sign treatment. However, it does not explicitly indicate when NOT to use this tool or mention alternatives (e.g., prepare_aave_repay) for different protocols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description reveals key behaviors: decimals resolved from canonical table, return format (preview + opaque handle), fee-limit default, and Ledger display differences between USDT and other tokens. This adds meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five well-structured sentences with no redundancy. It front-loads the main action, then efficiently covers constraints, defaults, output, and device behavior. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains the output (preview + opaque handle) and covers important behavioral details (Ledger compatibility, fee default, token restrictions). It could be improved by mentioning error scenarios beyond rejection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The description adds some value by explaining the human-readable amount format and fee-limit override, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned TRC-20 transfer transaction, explicitly naming the canonical set (USDT, USDC, USDD, TUSD) and mentioning the TronGrid endpoint. This distinguishes it from related TRON tools like prepare_tron_trc20_approve and from generic prepare_token_send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs users to forward the result to send_transaction for Ledger signing, explains the default and override for fee_limit, and notes that unknown TRC-20s are rejected. It does not explicitly list alternatives for other token types, but the context of canonical set boundary is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent. The description adds value by stating hard-refusal conditions (not owned, zero liquidity) and clarifying that withdrawn tokens become tokensOwed (not immediately transferred to wallet), which is critical behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with bold emphasis on key points. Every sentence adds value, no redundancy. Front-loaded with the core purpose, then details. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no output schema), the description covers major behavioral aspects: purpose, param mutual exclusivity, validation rules, and protocol workflow (tokensOwed). Missing some param details like deadlineSec and slippage behavior, but overall sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%. Description adds context for liquidityPct and liquidity (mutual exclusivity, typical use) and for tokenId (ownership check). However, wallet, chain, slippageBps, acknowledgeHighSlippage, and deadlineSec are not explained in the description, leaving gaps for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned Uniswap V3 decreaseLiquidity transaction, specifying the verb (builds), resource (unsigned transaction), and scope (decrease liquidity from an existing position by tokenId). It distinguishes from sibling tools like prepare_uniswap_v3_collect and prepare_uniswap_v3_burn by explaining the protocol flow and typical follow-up steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: when to use (e.g., pass liquidityPct:100 for full close-out), mutual exclusivity of liquidityPct and liquidity, ownership and zero-liquidity refusal, and typical follow-up sequence (collect, then optionally burn). Lacks explicit comparison to alternatives like increase_liquidity but the protocol flow is well described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, readOnlyHint=false), the description adds that the wallet burns its own balance and receives native ETH, that it performs a pre-balance check and gives a clear error, and that it's cheaper than aggregators. No contradictions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the core purpose. It uses clear, direct language and avoids redundancy. It could be slightly more streamlined, but overall it is efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, parameters, and behavior, but lacks details about the return format (unsigned transaction object) and next steps for the caller. It mentions the alternative tool and balance checks, but does not explain how to utilize the built transaction. Given no output schema, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 33% description coverage (only amount has a schema description). The description significantly compensates for the amount parameter by explaining the format (decimal or 'max') and the 18-decimal standard. It also lists supported chains (matching the enum) but doesn't add extra for wallet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool's exact function: building an unsigned WETH withdrawal via WETH.withdraw(). It clearly distinguishes the resource (WETH on canonical contract) and verb (unwrap), and differentiates from sibling tool prepare_native_send for the wrap direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (for WETH unwrap) and points to an alternative (prepare_native_send for the wrap). It also notes that no approval is needed and that it's cheaper than a DEX, but does not explicitly list when not to use it beyond mentioning the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying 'No transaction is sent' and detailing the return of projected health factor and totals. It also explains multi-protocol support, which goes beyond annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no fluff. First sentence states purpose and return. Second sentence details protocol-specific parameters. Third sentence confirms no transaction. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and multi-protocol support, the description adequately covers the core functionality. It explains how to configure different protocols and what the tool returns. However, it lacks detailed output structure (e.g., return type of health factor) and edge cases, so slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate. It clarifies the 'protocol' parameter and its dependent parameters (market for Compound, marketId for Morpho). However, it does not explain 'wallet', 'chain', 'asset', 'amountUsd', or 'action' beyond listing action types. The description provides partial but insufficient detail for all 8 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates adding/removing collateral or borrowing/repaying debt on a lending position. It specifies the verb 'simulate', the resource 'lending position', and mentions returns (health factor, totals). This distinguishes it from sibling tools like prepare_* which actually execute transactions, and from get_lending_positions which reads current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides when to use (e.g., 'No transaction is sent' indicates it's for preview). It lists supported protocols and how to specify them (protocol, market, marketId). However, it does not explicitly state when not to use or provide alternatives like 'use prepare_* for actual execution', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by explaining the current limitation (returns 'not-implemented' with explanation) and the reasons (missing APDU, CA, algorithm). 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but somewhat verbose, covering both intended and current behavior, sibling defenses, and future plans. It is front-loaded with 'READ-ONLY Secure Element attestation challenge', but could be more concise by separating the limitation from the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format ('status: "not-implemented"' with structured explanation) and provides context about sibling tools and the research gap. This is complete for a tool in development.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params, 100% coverage). The description does not need to explain any parameters, and it appropriately avoids adding unnecessary information. Baseline score for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the intended behavior: issue a nonce APDU, receive attestation, verify against Ledger's root CA. However, it also notes the current implementation returns 'not-implemented'. The tool's purpose is well-defined but not fully operational, which reduces clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the tool is READ-ONLY, lists sibling tools that cover the threat surface in the meantime (e.g., verify_ledger_firmware, verify_ledger_live_codesign), and explains that the cryptographic check is pending research. This provides clear guidance on when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds beyond annotations: describes error handling on body mismatch, return of per-input signature count, and 'No device touch' (no hardware interaction). No contradictions with annotations (destructiveHint=true, idempotentHint=true are consistent with merging operation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with core purpose, then constraints, error behavior, and output. No extraneous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers return value (merged PSBT + signature count), error handling, and constraints. Covers all essential aspects for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'psbts' is fully described in schema (100% coverage). Tool description repeats same constraints, adding no new information beyond the schema's description. Baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it merges 2-15 partial PSBTs from multi-sig cosigners, with clear constraints on input format (base64 v0, same unsigned tx body). Distinguishes from sibling tools like sign_btc_multisig_psbt and finalize_btc_psbt by focusing on combination step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear conditions for use (same unsigned tx body, only witness data differs) and error behavior when violated. Could explicitly mention not to use with PSBTs from different transactions, but the constraints imply this. Alternative tools are identifiable from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the tool is backed by a configurable indexer, notes the block time context, and references an issue explaining why the tool was missing. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded, but includes some extraneous details (e.g., issue reference, env var name). Could be slightly more streamlined, but overall efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description covers the return fields, configuration options, and behavioral context. It mentions the tool is a mirror of a Bitcoin counterpart and explains block time implications. Minor omission: does not explicitly describe output format (e.g., JSON object), but the listed fields imply structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters and 100% coverage, so bar for parameter semantics is high. The description does not need to add parameter info; it appropriately focuses on output fields and configuration. Baseline 4 for zero-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a read-only tool to get the current Litecoin mainnet chain tip, mirroring get_btc_block_tip, and specifies returned fields (height, 64-hex hash, timestamp, ageSeconds, optional MTP + difficulty). It distinguishes from sibling tools like get_btc_block_tip and get_ltc_chain_tips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context about the tool being a mirror of get_btc_block_tip, notes the block time difference (2.5 min vs 10 min), and mentions configurability. However, it does not explicitly state when to use this tool versus alternatives, nor does it give exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds context about the underlying data source (litecoind), configuration requirement, and cost comparison. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description includes extraneous information like issue numbers and cost comparison details that are not directly needed for tool invocation. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides adequate context: read-only, mirror of BTC version, requires configuration, and purpose. Complete enough for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so description does not need to add parameter meaning. The description is clear about the tool's input-less nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is READ-ONLY and returns the litecoind getchaintips output, mirroring get_btc_chain_tips for LTC. This specific verb+resource distinguishes it from siblings like get_ltc_block_tip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions when to use (for indexer-independent second opinion) and that it requires LITECOIN_RPC_URL configured. It implies mirroring get_btc_chain_tips, but does not explicitly provide when-not or direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds context on return values (staked amounts, USD value, APR, delegation target), which is useful beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the action, second lists returns. No unnecessary words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers return fields and supported chains implicitly. It is complete for a read-only query tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for wallet and chains. The tool description does not add significant extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies fetching Lido and EigenLayer staking positions for a wallet, detailing returned data (amounts, USD value, APR, delegation target). It distinguishes from siblings like get_staking_rewards (rewards-focused) and get_solana_staking_positions (Solana-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Lido/EigenLayer positions but does not explicitly state when to use it over alternatives or when not to use it. It is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: it explains fault tolerance for address-type failures, mentions that taproot pairing is forward-compat only due to Litecoin Core not activating Taproot, and notes the reliance on USB HID via a specific SDK. Annotations only provide idempotentHint, so the description adds substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single coherent paragraph that front-loads the purpose and requirements, then adds technical details. It is informative without being overly verbose, though it could benefit from clearer sectioning. Overall, concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main aspects: pairing process, requirements, error handling, and references the output location (get_ledger_status). Without an output schema, it provides enough context for an agent to understand the tool's behavior and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive descriptions for both parameters (accountIndex and gapLimit) with 100% coverage. The description adds marginal value, such as mentioning BIP-44 coin type 2 and gap-limit scanning, but these are already implied or stated in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to pair a directly-connected Ledger device for Litecoin signing. It details the process of enumerating four BIP-44 address types and walking chains, which distinguishes it from sibling pairing tools for other blockchains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists requirements (Ledger plugged in, unlocked, Litecoin app open) and explains the tool's behavior, including fault-tolerant per-type failure. It does not explicitly contrast with alternatives, but the requirements and blockchain specificity provide clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool only builds an unsigned transaction (not executes), returns a handle and preview for Ledger signing, and explains why no approval is needed. Annotations (destructiveHint=true, idempotentHint=true) are consistent; description adds value beyond annotations by clarifying the signing flow and token resolution behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loads purpose and key details. No wasted words, though the explanation of the borrow mechanism could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description explains the return value (handle + readable preview). Also covers prerequisite (collateral), no-approval aspect, and market resolution. Lacks explicit details about the handle or preview format, but sufficient for a prepare tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds meaning by clarifying that 'amount' is human-readable (not raw wei) and that 'market' resolves the base token on-chain. This supplement is helpful beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it builds an unsigned Compound V3 borrow transaction, explaining the mechanism (withdraw beyond supplied balance) and that the base token is resolved on-chain. This distinguishes it from sibling tools like prepare_compound_supply, prepare_compound_repay, and prepare_compound_withdraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: requires sufficient collateral in the market, points to get_compound_positions to check collateral, and notes no approval step is needed. It implicitly differentiates from similar tools (supply, repay, withdraw) but does not explicitly list alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and idempotent behavior. The description adds important context: it explains the hash computation, the need for subsequent steps, and flags DELEGATECALL as high-risk. It does not contradict annotations and provides value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured, starting with purpose and then explaining details. Every sentence adds value, though it could be slightly trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the return type (UnsignedTx for approveHash) and the required subsequent steps (broadcast, submit_safe_tx_signature). It covers the tool's role in a multi-step process well, though it omits error conditions or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description carries the burden. It explains the inner parameter's two forms (handle vs raw to/value/data), the operation default and risk, and implies nonceOverride's purpose. However, it does not detail signer, safeAddress, or chain beyond what is obvious from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it proposes a Safe multisig transaction, distinguishes from siblings by detailing the specific flow (on-chain approveHash vs off-chain), and mentions related steps like submit_safe_tx_signature. It also contrasts with off-chain signing, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: recommends using a handle from prepare_*, describes the flow from this tool to broadcast to submit_safe_tx_signature, warns about DELEGATECALL risk, and notes the on-chain flow. However, it does not explicitly contrast with the other Safe tx tools (approve, execute) or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: it discloses the return value (preview + opaque handle), the need to forward via `send_transaction` for USB-HID signing, and the error condition. Annotations (`destructiveHint: true`, `idempotentHint: true`) are consistent and supplemented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. Every sentence serves a distinct function (purpose, usage hint, prerequisite, output, next step). No wasted words despite covering multiple aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully explains the workflow, prerequisites, error case, and return value. It references a related tool (`get_tron_staking`) and the follow-up step (`send_transaction`), making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter `from`, and the schema description already explains the parameter well. The tool description repeats similar information, adding no new semantic insight beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's verb ('Build an unsigned TRON WithdrawExpireUnfreeze transaction') and resource ('sweeps every matured unfreeze slice... back to liquid TRX'). It clearly distinguishes from sibling tools like `prepare_tron_unfreeze` by focusing on expired unfreezes and specifying no amount is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite ('Inspect `pendingUnfreezes` from `get_tron_staking` first') and warns of a specific error condition ('if every entry's unlockAt is still in the future... this tool errors'). Implicitly advises when to use, though does not explicitly contrast with alternatives like `prepare_tron_unfreeze`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral details beyond annotations: it hard-refuses when tokenId not owned, explains that the protocol auto-settles fee growth into tokensOwed, and notes that the tool builds an unsigned transaction (non-destructive). However, there is a potential contradiction with the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with about five sentences. It is front-loaded with the main action, uses clear language, and every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the output format of the unsigned transaction (e.g., hex bytes, structure). Given no output schema, the agent would need to know what to expect. It also does not cover prerequisites like needing a previous decrease liquidity call, though it mentions the source of owed tokens.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the input schema by explaining the default for recipient and implying wallet as owner. Schema coverage is 50%, so the description partly compensates. It does not explain chain or wallet formats beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it builds an unsigned Uniswap V3 LP collect transaction to harvest owed tokens and fees. It specifies the scope (every token, up to uint128.max) and distinguishes from sibling tools like prepare_uniswap_v3_burn and prepare_uniswap_v3_decrease_liquidity by its focus on collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: after decreasing liquidity or when fees have accrued. It also specifies prerequisites (tokenId must be owned by wallet) and explains the default and override for recipient. Clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent, and open-world hints. The description adds useful behavioral details: uses mainnet ENS resolver and returns null for unregistered names. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded with the action. Includes an example and behavior on failure. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description covers purpose, input (with example), network (mainnet), and return value (address or null). No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the 'name' parameter. The description adds meaning by specifying it as an ENS name with an example, but it lacks explicit format or constraints like 'must end with .eth'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool resolves an ENS name to an Ethereum address via mainnet ENS resolver, with an example and clarification that it returns null if unregistered. This distinguishes it from sibling tools like reverse_resolve_ens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly specifies when to use (when you have an ENS name and need the address) but does not explicitly mention when not to use or provide alternatives. However, the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds rich behavioral context beyond annotations: explains data sources (demo-mode, Ledger, tx history), output formats (envelope + narrative), redaction behavior, v1 limitations (no prepared-tx ring buffer), and roadmap. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded with purpose. Long but efficient, though some roadmap details could be condensed. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: behavior, outputs, redaction, scopes, incident classes, limitations, and roadmap. Adequate given no output schema and comprehensive schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions. The tool description reiterates some parameter context but adds little new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a forensic incident-report bundle for security review or disclosure, and distinguishes itself from siblings by noting it does not submit anywhere (roadmap for submit companion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (security review/disclosure) and explicitly states it only builds, not submits, and that submission is deferred. Provides guidance on redaction modes and scope selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm readOnly, non-destructive, idempotent. Description adds 'no wallet required' and details on returned fields (pause flags, collateral lists), providing full behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and use cases. Each sentence adds value, though slightly verbose in listing return fields. Could be tightened without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description exhaustively enumerates return fields (metadata, APRs, collateral details), making the tool's output fully predictable. Covers all needed context for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already has 100% description coverage for both parameters. Description lists return fields but adds no additional parameter-level detail beyond the schema, meeting baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch structured market info for a single Compound V3 (Comet) market — no wallet required' and lists specific data returned, distinguishing from sibling tools like get_compound_positions which focus on user positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'explain market state', answer specific questions, and 'diagnose an incident'. Lacks explicit comparison to alternatives, but the use cases are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnly, idempotent, non-destructive. Description adds specific return fields (supply/borrow balance, collateral, valuations) and edge case behavior (empty list if no exposure), confirming safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently pack purpose, return details, usage context, and edge case. Front-loaded with action verb. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects for a read-only tool: what it does, what it returns, when to use, and empty result handling. Lacks explicit return structure details, but given no output schema, the listed fields are adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Tool description mentions 'selected chains' but schema already covers default behavior. Minimal additional value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies the exact verb 'Fetch', resource 'Compound V3 positions for a wallet', and scope 'across all known markets on selected chains'. It lists returned data fields (supply/borrow, collateral, USD valuations) and distinguishes itself from siblings by recommending use before prepare_compound_* actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: to answer 'my Compound positions' or before preparing a Compound action to get the market address. Provides interpretation of empty result. Does not explicitly exclude other uses, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description details return structure (obligation PDA, per-reserve deposits/borrows, USD values, health factor with convention explanation), and clarifies edge cases (empty list for new wallets, warnings for pause/freeze). 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph but front-loaded with 'READ-ONLY' and efficiently covers all key points without redundancy. Slightly dense but earns each sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains what the tool returns, including health factor conventions, empty list handling, and warnings, making it fully contextual for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter description, so baseline is 3. The tool description adds some extra context (health factor and warnings) but does not significantly enhance parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it enumerates a Solana wallet's Kamino lending position on the main market, specifying both the resource (Kamino) and context (main market), which clearly distinguishes it from other position tools like get_marginfi_positions or get_compound_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when it returns empty (wallet never used Kamino), providing implicit guidance on when to use. However, it does not explicitly state when to prefer this over alternatives, though the naming and context naturally differentiate it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds valuable behavioral details beyond annotations: auto-discovery performance warning, fast path suggestion, and return content. Annotations already indicate read-only, idempotent, non-destructive; description enriches with operational nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, key behavioral nuance, and return content. No redundant or superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description clarifies return categories (supplied/borrowed assets and collateral) per market. Lacks output format specifics but adequate for a query tool. No mention of limits or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; tool description adds context about marketIds auto-discovery vs explicit fast path. However, the wallet parameter schema description uses 'execute this action' which slightly misaligns with the read-only nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching Morpho Blue positions for a wallet, specifying the resource (Morpho Blue) and action (fetch). It distinguishes from sibling tools like get_compound_positions by explicitly naming the protocol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises on when to use explicit marketIds for speed versus omitting them for auto-discovery, but does not explicitly contrast with sibling tools for mutations (e.g., prepare_morpho_*). The readOnlyHint annotation reinforces the read-only nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint false) already convey safety. The description adds substantial behavioral details: the dropped detection logic on Solana via durableNonce/lastValidBlockHeight, the diagnostic fields returned, and the risk of pending forever without proper fields. However, it does not explicitly mention network error handling or timeouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that packs a lot of information, but it would benefit from breaking into subsections per chain or usage pattern. It is not overly long, but the structure could be improved for easier parsing by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately covers return values (pending, success, failed, dropped) and special cases (e.g., Solana dropped detection). It does not detail error conditions like network failures or timeouts, but the core behavior is well-explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter descriptions. The description goes further by explaining the roles of durableNonce and lastValidBlockHeight in drop detection, how they are obtained from send_transaction, and the consequences of missing them. This adds meaningful context beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls transaction status across multiple chains (EVM, Solana, Tron, Bitcoin) and specifies the exact return states (pending/success/failed/dropped). It distinguishes itself from siblings like send_transaction and explain_tx by focusing on post-send polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the tool (after sending a transaction) and, for Solana, provides critical guidance on passing the correct drop-detection field (durableNonce or lastValidBlockHeight) to avoid pending forever. It also notes that omitting these fields leads to a known UX gap, effectively telling the agent when not to rely on results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces read-only nature and adds behavioral details: the resource meter vs frozen TRX distinction, the shape of votes[], and that it avoids side effects. No contradictions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and structured with parentheses and code references, but every sentence serves a purpose. It could be slightly trimmed, but the front-loaded enumeration of returned fields is effective. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully specifies all return components (rewards, frozen TRX, unfreeze timestamps, resource meter, votes) and their semantics. It also explains the relationship to other tools (prepare_tron_claim_rewards, prepare_tron_vote, list_tron_witnesses) and a known issue (#271). Complete guidance for a read-only query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'address' is fully described in the input schema (pattern, example, purpose). The description uses the address in context but does not add new semantic constraints beyond the schema. With 100% schema coverage, baseline is 3; no extra value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Read TRON staking state' and enumerates all returned data components (rewards, frozen TRX, pending unfreezes, resource meter, votes). It clearly distinguishes from sibling tools like prepare_tron_claim_rewards and prepare_tron_vote by positioning itself as the read-only precursor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: to obtain current staking state before claiming rewards (prepare_tron_claim_rewards) or rebalancing votes (prepare_tron_vote). It explicitly contrasts with list_tron_witnesses, noting that votes[] here avoids a chained call. Provides both positive and negative usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, non-destructive, idempotent, and open-world. The description adds critical behavioral details: strict-fail on tamper with specific error types, unsigned in-memory entry merging, demo mode override, and per-(label, chain) conflict resolution. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose, then adds important details about tamper handling, unsigned entries, and demo mode. While somewhat dense, each sentence provides value. Minor redundancy in discussing 'unsigned: true' flag, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return format (fields like label, addresses, notes, addedAt, unsigned flag). It covers error conditions, edge cases (unsigned entries, demo mode), and parameter semantics. For a read tool with two optional parameters, this is comprehensively complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds meaning beyond the schema: it explains that omitting 'chain' returns all chains, and using 'label' performs a single-record lookup. This clarifies the default behavior and use case for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a 'joined per-label view across chains' with specific fields (label, addresses, notes, addedAt, unsigned flag). This differentiates it from sibling tools like 'verify_contacts' (which only verifies) and 'add_contact' (which modifies). The verb 'Return' and the resource 'per-label view' make the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the optional 'chain' and 'label' parameters: filter by chain or single record search. It also mentions the strict-fail behavior on tamper, guiding agents to surface errors. However, it does not explicitly state when not to use this tool or provide alternatives, though the sibling list implies other contact tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral details (enumerates four address types, caching, mainnet-only, gap-limit scanning) beyond annotations. However, there is a contradiction: annotations set readOnlyHint=false while description claims 'Read-only on the device,' which may mislead the agent about side effects. IdempotentHint=true is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and requirements, then details address types and caching. It is slightly long but every sentence adds value. Minor verbosity in listing sibling tools and phase info, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two optional parameters and no output schema, the description fully explains what the tool does, how it works (address derivation, caching), and constraints (mainnet-only, device requirements). No gaps remain for an agent to understand its usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with detailed descriptions for both parameters. The description further adds context by explaining that a single call enumerates all four address types and walks both chains, and that gap-limit scanning is used. This enriches the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pairs a directly-connected Ledger device for Bitcoin signing, distinguishing it from sibling tools like pair_ledger_live (which uses WalletConnect) and pair_ledger_ltc (Litecoin). Verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit requirements are provided (USB plugged, device unlocked, Bitcoin app open). It explains when not to use (Ledger Live WalletConnect relay doesn't expose bip122 accounts) and gives context on alternative pairing methods. Instructions for calling with different accountIndex are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: explains it reads device address at a derivation path and caches it, and that it's idempotent (multiple calls with same accountIndex re-cache). Annotations already indicate idempotentHint=true and non-destructive, so description reinforces and adds detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, requirements, technical details, usage, and error info. Slightly verbose but all sentences add value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers prerequisites, usage pattern, error conditions, and cross-references related tools (get_ledger_status, prepare_solana_*, send_transaction). No output schema needed for such a simple tool; description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, accountIndex, already has a thorough description in the schema (100% coverage). The description repeats the derivation path and default value, and adds context about multiple calls. It adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pairs a Ledger device for Solana signing via USB HID. It specifies the derivation path and distinguishes from siblings like pair_ledger_tron by mentioning shared USB path and from WalletConnect alternatives by stating they don't work for Solana.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit requirements (Ledger plugged, unlocked, Solana app open) and usage pattern: call once per session per account before prepare_solana_* or send_transaction. Also explains calling multiple times for additional accounts and error handling when conditions fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true. Description adds behavioral context: it builds an unsigned transaction (no execution), includes an ERC-20 approve step if needed, and supports 'max' for full repayment. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Each sentence provides critical details: purpose, encoding, approval step, and amount notation. Extremely concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and five parameters, the description covers the main behavior, approval step, and the 'max' feature. It lacks details on return format, but for a preparation tool, this is acceptable. The description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds semantic value beyond schema: 'encoded as supply(baseToken)', 'includes an approve step if needed', and explains approvalCap parameter (omit for unlimited, 'exact', or specific decimal string). The 'max' usage for amount is also explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it builds an unsigned Compound V3 repay transaction, encoded as supply(baseToken) against an outstanding borrow. It distinguishes from other compound actions (borrow, supply, withdraw) by specifying 'repay' and mentions the include of an approve step, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to repay a borrow on Compound V3) and how to use it (pass amount as 'max' for full repay). While it doesn't explicitly state alternatives or when not to use it, the context is clear given the sibling tools like prepare_compound_borrow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent nature, but the description adds crucial behavioral context: no ephemeral keypair (Ledger-compatible), ATA auto-creation with reclaimable rent, durable nonce requirement, blind-sign warning, and future roadmap for unstaking. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, front-loaded with the core action. While efficient, it could benefit from bullets for caveats (nonce, blind-sign, ATA rent) to improve readability. Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not specify the structure of the returned unsigned transaction (e.g., format, fields). This leaves a gap for the agent regarding what to expect from the tool's output. Annotations help with safety but not return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with detailed descriptions. The description adds practical context (wallet must have nonce and enough SOL for deposit+rent+tx fee; amountSol is human-readable with 9 decimals), enriching the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool builds an unsigned Jito stake-pool deposit transaction, specifying the program, instruction, and what the user receives (jitoSOL). It distinguishes itself from other staking tools by naming Jito and providing unique details (no ephemeral keypair, Ledger-compatible).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites (durable nonce must be initialized), warns about blind-signing on Ledger, and mentions that unstaking is not yet available. However, it does not contrast with alternatives like native staking or other LSTs, so the agent must infer use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true. The description adds significant behavioral context: preconditions, LTV gate, simulation gate, durable nonce requirement, and blind-sign treatment. No contradictions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three to four sentences, all value-add. Front-loaded purpose, followed by preconditions, on-chain behavior, and additional requirements. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, preconditions, on-chain enforcement, simulation, and additional requirements (durable nonce, blind-sign). Missing explicit mention of return value, but as a preparation tool without output schema, the description is adequately complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The tool description adds meaning beyond the schema by explaining wallet must have userMetadata/obligation, mint must be on market, and amount is human-readable with decimals resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a Kamino borrow transaction, pulling liquidity as debt against existing collateral. It differentiates from sibling Kamino tools by specifying prerequisites (init_user, mint on market) and behavioral details like LTV gate and simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear preconditions (wallet must have run prepare_kamino_init_user and mint must be on main market), implicitly guiding when not to use it. However, it does not explicitly compare with other borrowing tools or scenarios, but the context is sufficient for a protocol-specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds significant behavioral details: pre-flight check for free collateral, SDK computes oracle refreshes, health-factor gate enforced on-chain, and error surfacing. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the core action. Every sentence serves a purpose: defining the tool, stating pre-flight behavior, noting on-chain enforcement, and listing prerequisites. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a borrow transaction and the absence of an output schema, the description covers key aspects: what it builds, pre-flight, prerequisites, and Ledger signing. It does not explicitly state the return format (unsigned transaction), but the purpose implies it. Sibling tools are many, but the description sufficiently differentiates from other prepare_marginfi tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add much meaning beyond the schema's already detailed parameter descriptions (e.g., 'symbol' and 'mint' are well-documented). The description mentions 'human-readable decimal amount' but that's also in the schema. Minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned MarginFi BORROW transaction against supplied collateral. It specifies the action (borrow), protocol (MarginFi), and distinguishes from similar tools like prepare_marginfi_supply by noting identical prerequisites. The pre-flight condition for free collateral adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: prerequisites (DURABLE NONCE + prepare_marginfi_init) are identical to prepare_marginfi_supply, and the tool surfaces clear errors instead of reverting on-chain. It mentions Ledger blind-sign, which guides signing. However, it does not explicitly state when not to use this tool versus alternatives like Kamino borrow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by specifying the transaction is unsigned, the token type (supplied loan token), and the constraint on amount ('max' not supported). No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using a single sentence plus a clarifying note. It front-loads the core purpose, making it immediately actionable without any redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers essential aspects: purpose, amount constraint, and a hint to query positions. It could mention the need to send the transaction afterwards, but the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by clarifying that 'max' is not supported and suggesting to query positions for the marketId, enhancing the schema's details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool builds an unsigned Morpho Blue withdraw transaction for a supplied loan token, clearly distinguishing it from sibling tools like prepare_morpho_borrow or prepare_morpho_supply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly warns that 'max' is not supported and advises querying positions first, providing clear when-to-use guidance. However, it could explicitly mention alternatives for max withdrawals, such as using a different tool or manual calculation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals it returns an UnsignedTx that calls Safe.approveHash, consistent with annotations (destructiveHint=true). Adds procedural detail beyond annotations, but could elaborate on idempotency or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: purpose+condition, output+workflow, alternative. No wasted words, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity and lack of output schema, the description explains the tool's role, output type, and relationship to siblings. Could include more on prerequisites (like ensuring tx exists in queue), but sufficient for correct selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions signer and safeTxHash in context but does not explicitly describe each parameter. Chain default is stated elsewhere but not in description. Adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds an approveHash signature to an already queued Safe transaction. It uses specific verb 'Add', resource 'approveHash signature', and distinguishes from sibling tool prepare_safe_tx_propose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (tx already proposed elsewhere) and when not (use prepare_safe_tx_propose for new proposals). Also provides sequential workflow: broadcast via send_transaction then submit_safe_tx_signature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and not readOnly. The description adds behavioral context: costs (0.00144 SOL + tx fee), rent reclaimability via close, and use of regular recent blockhash. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with front-loaded purpose, alternative info, use cases, costs, and behavior. It is dense but clear; slight improvements could be made by breaking into bullets, but current is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter (fully documented in schema), no output schema, and annotations provide basic hints, the description covers purpose, alternatives, when to use, cost, reclaimability, refusal condition, and technical blockhash detail. It is comprehensive for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema's own description for 'wallet' is already detailed (derivation, no backup needed). The tool description reiterates the derivation string but adds no significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the explicit one-time setup of a per-wallet durable-nonce account at a specific deterministic PDA. It distinguishes from sibling tools like prepare_solana_native_send by noting that most users do not need to call this directly because those tools auto-bundle the setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (standalone before Jupiter swap or MarginFi action, or to re-init after close) and when not to (most users should rely on auto-bundling). It also mentions that it refuses if a nonce account already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond annotations (destructiveHint, readOnlyHint) by detailing automatic ATA creation with rent cost disclosure, nonce setup, and blind-sign requirements. It explains the Ledger app behavior and user actions needed. No contradictions 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very verbose (400+ words) with multiple sections. While it front-loads the main purpose, it includes lengthy technical details about blind-sign that could be summarized. Conciseness is adequate but not optimal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (SPL send with ATA, nonce, Ledger blind-sign), the description covers the workflow, prerequisites, behavioral nuances, and user responsibilities. It lacks error handling details but is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers parameters with descriptions, but the description adds significant context: known token mints, resolution of decimals for amount, automatic ATA rent cost, and nonce setup. This adds meaning beyond the schema, especially for amounts and mint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned SPL token transfer draft via Token.TransferChecked, distinguishes it from native SOL sends and other Solana tools, and specifies what it does not do (serialize/fetch blockhash). The verb 'Build' and resource 'unsigned SPL token transfer DRAFT' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear workflow: call this tool first, then preview_solana_send(handle), then send_transaction. It mentions prerequisite (pair_ledger_solana) and includes context on when to use (for SPL sends) and blind-sign requirements. However, it does not explicitly state when NOT to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: it clarifies the tool builds an unsigned transaction (not yet on-chain), mentions the 'max' special case and token disambiguation workflow. Annotations already indicate destructive and idempotent hints, which align.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main purpose, followed by special behavior. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers what the tool does and important usage notes. It could mention that the output is an unsigned transaction to be used with other tools, but the purpose is sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 20% schema description coverage, the description compensates by explaining the 'max' value for amount and giving context for token disambiguation. It adds meaning for two key parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it builds an unsigned ERC-20 transfer transaction, using specific verb (build) and resource (unsigned ERC-20 transfer). It distinguishes from siblings like prepare_native_send by specifying token and mentioning resolve_token for symbol disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to call resolve_token first if the user provided a token symbol, and explains the special 'max' amount usage. However, it does not explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true and idempotentHint=true. The description adds that burning destroys the NFT irreversibly and clarifies refusal conditions (liquidity==0, tokensOwed==0). This goes beyond annotations by detailing failure modes, but could further explain idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action and irreversibility. The structure is efficient, with no filler. Every sentence adds value: purpose, refusal conditions, usage sequence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex destructive tool, the description covers the flow, prerequisites (fully drained), and ties to sibling tools. No output schema exists, so return values are not needed. It lacks mention of gas or confirmation requirements, but the main context is sufficient for the agent to decide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only tokenId described). The description adds crucial context for tokenId: must be owned by wallet and position fully drained. However, wallet and chain parameters are not elaborated beyond their schema types/enums, so the description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it builds an unsigned Uniswap V3 LP burn transaction and destroys the position NFT irreversibly. It clearly distinguishes from sibling tools like prepare_uniswap_v3_collect and prepare_uniswap_v3_decrease_liquidity by specifying it as the final step in the close-out sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: only after decreasing liquidity and collecting fees. It gives the standard sequence (decrease → collect → burn) and states that the tool hard-refuses unless the position is fully drained, with error messages naming the next step. This helps the agent avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses detailed behavior: descriptor construction, fingerprint verification, on-device confirmation process, HMAC persistence, and xpub validation. Annotations already provide idempotentHint, and the description adds rich behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and front-loaded with core purpose and requirements. While a bit lengthy, every sentence adds value. Could be slightly tighter but is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and lack of output schema, the description covers prerequisites, process steps, limitations (Phase 2), and mentions related tools. It is complete for an agent to understand usage and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema descriptions are already comprehensive. The tool description adds context (e.g., BIP-388, HMAC reuse) but does not significantly enhance per-parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers a multi-sig Bitcoin wallet policy with the Ledger BTC app (BIP-388). It uses specific verbs and resource, distinguishing it from siblings like sign_btc_multisig_psbt and unregister_btc_multisig_wallet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists requirements (Ledger connected, unlocked, Bitcoin app open) and scope (Phase 2, P2WSH only). It implies this is a one-time setup before signing, but does not explicitly state when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the removal process across chains, conditions for dropping unsigned metadata, error codes (CONTACTS_LABEL_NOT_FOUND), and Ledger pairing needs. It also references issue #428 for additional context. No contradictions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and well-organized, but slightly verbose. It front-loads the core action and then provides conditional explanations. Every sentence adds value, though some complexity could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers behavior and error conditions thoroughly but omits the return value or confirmation of success. Since no output schema exists, this gap reduces completeness for an agent expecting a response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions (100% coverage). The description adds extra meaning by explaining the effect of the chain parameter on removal scope and the concept of signed vs unsigned entries. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a labeled contact and distinguishes behavior with and without the chain parameter. It references siblings like add_contact and list_contacts implicitly, and the name is self-explanatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the chain parameter (to remove from a specific chain) versus omitting it (remove from all chains). It also covers Ledger requirements for different scenarios. However, it does not explicitly mention when not to use this tool compared to siblings, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the annotations: explains per-chain failure handling (no throw), special cases for unsigned entries (with specific reason and field), and demo mode behavior. Annotations already declare read-only, idempotent, open-world hints, but the description enriches these with concrete outputs and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and return format, followed by use case and important behavioral notes. It includes issue reference and two edge case explanations. While informative, it is slightly dense; could be more structured (e.g., bullet points), but remains clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return structure including all fields, optional fields, and special cases (unsigned entries, demo mode). It covers expected behavior for different scenarios, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full description for the optional 'chain' parameter with enum values and behavior. The description does not add new semantic meaning about the parameter itself; it focuses on return values. With 100% schema coverage, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an 'Explicit re-verify' tool, specifies the return format per chain, and distinguishes its purpose as periodic integrity checks or tamper event response. It is specific and contextualized among many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives use cases ('periodic integrity checks or after a suspected tamper event'). It notes that it does not throw on per-chain failure, guiding how to handle results. However, it does not provide explicit alternatives or when-not-to-use compared to sibling verification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description confirms the token creation is a mutable operation (issuer-side record). It adds behavioral details: token returned once, hash-only storage, revocation semantics. Minor gap: not stating that generating a token is non-reversible beyond revocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than optimal but each sentence adds value. It front-loads the main purpose and proceeds through use case, token properties, security model, and related tools. Slightly verbose, but no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description is remarkably complete. It covers the entire workflow: generate, share, import, query; explains token security (sha256, public data); and references sibling tools for revocation and listing. The agent can confidently use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all four parameters in detail: wallets (with chain-specific regex validation), scope (read-portfolio only), expiresIn (with defaults), and name (auto-default pattern). Since the schema has 0% coverage, the description fully compensates, even clarifying the wallet structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a time-bound, revocable token for read-only access to specific wallets. It distinguishes this from similar tools by emphasizing that it creates a shareable token rather than performing direct reads. The mention of the classic use case with a financial advisor further solidifies clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (granting temporary read-only access) and mentions related tools like import_readonly_token and revoke_readonly_invite. It lacks explicit guidance on when not to use it, but the context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds value by detailing output fields (txid, sats, fee, block info, RBF flag) and the Esplora page limit, which are not 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the most critical information (read-only, what it returns, ordering). Every sentence adds value; no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately covers all return fields and behavioral aspects (RBF flag, pagination cap). It is self-contained and sufficient for an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters already described. The description adds useful context (e.g., 'one Esplora page' for limit, 'newest-first' ordering) that goes beyond the schema descriptions, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states specific verb+resource: 'Bitcoin transaction history for a single address (newest-first)' and details the data fields. Distinguishes from siblings like get_btc_account_balance (balance only) and get_transaction_history (likely multi-address).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly marks as READ-ONLY, explains the limit and cap behavior, and notes pagination limitation ('pagination beyond is a follow-up'). While not detailing alternatives, the description provides clear context for proper use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description details exact return values, filtering of zero-balance pools, and the additive expansion strategy. This provides agents with a clear understanding of tool behavior without hidden side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with core purpose and constraints, then details return values and future plans. While slightly verbose, every sentence serves a purpose. Could be slightly tightened but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return value specifics and filtering behavior adequately. It addresses current scope and future expansions, though it omits error handling or edge cases. Still, it is sufficiently complete for v0.1.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema parameter description is already quite detailed, including scope limitations. The main description does not add significant new meaning about the paramter beyond reinforcing the context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Curve LP positions on Ethereum stable_ng plain pools, specifying return fields (LP token balance, gauge-staked, pending CRV) and filtering behavior. It distinguishes itself from sibling tools like get_lp_positions and get_compound_positions by focusing on a specific protocol and pool type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use (Ethereum stable_ng plain pools) and when not to (meta pools rejected). It also outlines future expansions and references a planning document, providing clear context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive, and open-world. The description adds significant detail: it always enumerates personas regardless of state, specifies response format, and explains the matrix enrichment (rehearsableFlows, flowGaps, recommendations). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and contains multiple paragraphs with interleaved details. While all information is valuable, it could be better structured (e.g., bullet points for response shape or matrix explanation) to improve readability for an agent. It's functional but not lean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully defines the response structure including all fields and their meanings. It covers edge cases (envState values, matrix enrichment) and provides complete guidance for the agent to act on the result. The complexity is high, and the description meets it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters. With no parameters, baseline is 4. The description does not need to explain parameters, and it correctly mentions that no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: report active demo wallet, confirm default demo mode, or explain why demo mode isn't active. It also enumerates personas and provides response structure, clearly distinguishing it from siblings like set_demo_wallet and exit_demo_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises reading matrix data before user picks a flow to offer rehearsable flows and avoid unsupported ones. While it provides usage context, it doesn't explicitly state when not to use or mention alternative tools, but the guidance is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true, openWorldHint true. The description adds specifics: READ-ONLY, default 144 blocks (~6h), capped at 200, and internal usage context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight three-sentence paragraph, front-loaded with 'READ-ONLY', and every sentence adds value (function, defaults, internal usage). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately specifies it returns block headers newest-first, with defaults and cap. It mentions internal usage and issue reference. Minor omission: could briefly note typical fields in a block header, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single limit parameter. The description adds reasoning for the cap (to bound HTTP fan-out on litecoinspace.org's tighter free tier), providing meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches recent Litecoin block headers, newest-first, with default limit and cap. It explicitly mirrors get_btc_blocks_recent for LTC, distinguishing it from sibling tools like get_ltc_block_tip or get_ltc_block_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is used internally by get_market_incident_status for LTC and mentions the cap bound due to API tier. However, it does not explicitly state when to use this tool versus alternatives like get_ltc_block_tip or get_ltc_block_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, etc. Description adds substantial behavioral context: probes account indices 0-3, returns per-account entries with balances, USD values, health factor with interpretation (>1 safe, Infinity when no debt), and bank-level pause warnings. Contradiction false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph of 4 sentences. Every sentence adds value: opens with 'READ-ONLY', then describes action, scope, return details, and parallelism. Zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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, the description covers return structure, health factor interpretation, aggregate totals, warnings field, and empty array case. No output schema exists, so the description adequately explains what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description for 'wallet' already includes the probing detail. The tool description repeats this without adding new meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'enumerate' and resource 'MarginFi lending positions' for a Solana wallet. It clearly distinguishes from siblings by explicitly naming parallel tools (get_compound_positions, get_morpho_positions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context: it is read-only, probes first 4 accounts, and returns empty array if no positions. It mentions parallels to other tools, giving implicit guidance on when to use this vs alternatives, but lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the tool is safe to call repeatedly. The description adds behavioral details about return fields (amount, decimals, symbol, USD value) and chain-specific balance types (TronBalance, SolanaBalance). This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured: general purpose first sentence, then chain-specific instructions. It is front-loaded and logically organized. Could be slightly more concise, but the information density justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all chains in the enum (ethereum, tron, solana) with specific wallet/token formats. Since there is no output schema, it explains return fields (amount, decimals, symbol, USD value) and balance types. For a multi-chain balance tool, this is comprehensive and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter descriptions. The description fully compensates by explaining each parameter: wallet (address format hinted), token ('native' or contract address), chain (optional, default ethereum). It provides concrete examples (e.g., 'Pass `token: "native"` for ETH') and chain-specific formats, making the meaning clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a wallet's balance for any ERC-20 token or native coin, and distinguishes between Ethereum, TRON, and Solana chains with specific instructions. It provides a specific verb ('Fetch') and resource ('wallet's balance'), making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context for different chains (e.g., 'For TRON, pass chain: "tron"' and gives wallet/token format details). It implies when to use this over other tools (e.g., for balance queries), but does not explicitly state when not to use or list alternatives. Given the many sibling tools, this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by disclosing proxy detection and implementation address return, which is beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the core purpose and key features, with no extraneous information. Every sentence is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers what the tool does, what it returns (metadata plus implementation address), and how to use it. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description implies address is a token address and chain is an EVM chain with defaults. However, it does not explicitly describe each parameter's meaning or constraints beyond what the schema provides. Adequate but not detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches ERC-20 metadata (symbol, name, decimals) for any token address on an EVM chain, and also detects proxies. This distinctly differentiates it from sibling tools that focus on balances, portfolios, or specific protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool over raw simulate_transaction calls for token metadata, and notes that no wallet or balance is required. This provides clear guidance on when to use it vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses behaviors beyond annotations: signs with Ledger, returns partial PSBT, uses coin-selection with multi-sig vbyte estimator, fee-cap guard, and pipeline steps. No contradiction with annotations (destructiveHint=true, idempotentHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but well-structured with a numbered pipeline. First sentence sums up purpose, and each step adds value. Slightly verbose but earn its sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately states return value (partial PSBT). Also covers prerequisites, pipeline steps, and limitations. Lacks some details like exact format of returned PSBT but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by explaining 'amount' can be 'max' to sweep, fee rate defaults to halfHourFee, and allowHighFee overrides cap. Also explains multi-sig vsize impact, adding clarity beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the initiator flow to build and sign a multi-sig transaction, returning a partial PSBT. It distinguishes from siblings like prepare_btc_send, combine_btc_psbts, and finalize_btc_psbt by outlining the specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (initiator flow) and what not to do (do not finalize or broadcast). Provides a pipeline and notes that Phase 3 supports only wsh wallets, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true. The description adds behavioral context: the tool fetches UTXOs, runs coin selection, builds a PSBT v0 with nonWitnessUtxo (Ledger requirement), and returns a handle for send_transaction. It also explains why legacy 3-prefix P2SH is rejected (bitcoinjs-lib limitation). No contradictions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences), front-loaded with the primary purpose, and each sentence conveys essential information without redundancy. It efficiently covers pipeline, constraints, and return usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema), the description fully covers the lifecycle: fetching UTXOs, fee estimation, coin selection, PSBT building with Ledger-specific requirements, and the subsequent send_transaction step. It also explains address type restrictions and their rationale, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 83% of parameters with descriptions. The description adds value beyond schema: for 'wallet', it clarifies that source addresses must be ltc1q or ltc1p in initial release; for 'to', it warns that legacy 3-prefix P2SH is rejected and advises using M-prefix; for 'feeRateSatPerVb', it states optional with default halfHourFee; for 'rbf', default true. 'allowHighFee' lacks extra context, slightly reducing completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned Litecoin native-send PSBT, detailing the pipeline (fetch UTXOs, fee rate, coin selection, PSBT v0 with nonWitnessUtxo). It differentiates from sibling tools like prepare_btc_send by specifying Litecoin specifics and constraints (source addresses must be ltc1q or ltc1p, recipients exclude 3-prefix P2SH).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for Litecoin native sends) by referencing the same pipeline as prepare_btc_send. It lists constraints such as address type restrictions and explicitly notes that 3-prefix P2SH recipients are refused. While it doesn't explicitly state when not to use alternatives, the Litecoin-specific focus provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and idempotent. Description adds that it builds an unsigned tx, mentions blind-sign on Ledger, and details repayAll behavior (clears balance slot). 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core purpose. Each sentence provides essential information without redundancy. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description clearly states return is an unsigned transaction. Covers prerequisites, parameter behavior, and Ledger consideration. Complete for a transaction-building tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. Description adds meaning: explains symbol resolution to mint, SOL treated as wSOL, repayAll clears slot and is cheaper. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned MarginFi REPAY transaction against outstanding debt, with specific verb 'repay' and resource 'MarginFi bank'. It distinguishes from siblings by referencing 'prepare_marginfi_supply' for prerequisite pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites (durable nonce, prepare_marginfi_init) and guidance on repayAll (clears balance slot, cheaper for closing). However, lacks explicit when-not-to-use vs other marginfi tools like borrow or withdraw.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint, readOnlyHint), the description adds key behaviors: 'max' closes the account and reclaims rent-exempt seed, partial withdrawals leave it open; the stake must be inactive; durable nonce required; same Ledger treatment as delegate. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only four sentences to convey all key information without fluff. It front-loads the purpose and packs behavioral details, prerequisites, and parameter clarifications efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters, no output schema, and existing annotations, the description covers all necessary context: tool action, behavioral nuances, prerequisites (inactive stake, durable nonce), and parameter special values ('max'). It also mentions error handling (simulation gate). No gaps for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all three parameters (100% coverage). The description adds valuable context: clarifies that 'max' closes the account, explains the wallet must be the withdrawer authority, and reinforces the inactivity condition for stakeAccount. This enhances parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned native-stake withdraw transaction, distinguishing between closing the account ('max') and partial withdrawal. It specifies the source (inactive stake account) and destination (wallet). This clearly differentiates it from siblings like prepare_native_stake_delegate or prepare_native_stake_deactivate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that the stake must be inactive (one full epoch after deactivate) and mentions the simulation gate catches errors. It also notes that a durable nonce is required and the Ledger blind-sign treatment is the same as prepare_native_stake_delegate. While it doesn't list all alternatives, it gives clear prerequisites and readiness conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral context beyond annotations: explains returned Solana v0 tx is blind-signed on Ledger, that source tx confirms first and delivery is async, and that builder rejects certain routes. Annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) are consistent with this behavior, and no contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long and contains some redundant phrasing (e.g., multiple mentions of LiFi routing). While it is front-loaded with purpose, the length could be trimmed without losing essential information. Adequately structured but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with two flows, Ledger signing, and no output schema, the description comprehensively covers purpose, usage conditions (durable nonce, blind-sign), rejection cases, and references to related tools (`prepare_solana_swap`, `preview_solana_send`). It sufficiently equips an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema itself has 100% description coverage, so baseline is 3. The description does not significantly enhance parameter understanding beyond the schema; it only provides high-level context (e.g., durable nonce for wallet, blind-sign). No new semantic depth is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned LiFi-routed swap or bridge with Solana as source chain. It distinguishes between in-chain swap (toChain='solana') and cross-chain bridge (toChain=EVM), and explicitly references the sibling tool `prepare_solana_swap` for the more direct in-chain path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs `prepare_solana_swap`, warns that reverse direction is not yet wired, states durable nonce requirement, and explains rejection of multi-tx and multi-signer routes. This helps the agent decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant value beyond annotations: it discloses the transaction flow (returns preview + opaque handle, forward via send_transaction), the 24-hour cooldown constraint, and the error behavior ('TronGrid will reject'). Annotations only mark destructiveHint=true, but description provides operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a distinct purpose: action, constraint, prerequisite, and output/next step. No redundancy, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (no output schema, need for prior tool, cooldown, and subsequent send_transaction), the description covers all necessary steps: prerequisite, behavior on failure, and how to proceed with the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the 'from' parameter as a Base58 address with cooldown mention. The description does not add new meaning beyond the schema (it only mentions 'owner's balance' implicitly). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Build an unsigned TRON WithdrawBalance transaction that claims accumulated voting rewards') and the resource ('owner's balance'). It distinguishes from siblings by specifying 'TRON claim rewards' and mentioning pairing with get_tron_staking, which is unique among the many prepare_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: pair with get_tron_staking first to read claimableRewards and avoid empty-claim builds. It also warns about the 24-hour cooldown and potential rejections. However, it does not explicitly exclude other tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey destructive and idempotent nature. The description adds valuable context: user signs via Ledger, bridge delivery time (1-15 min), builder cross-checks, and blind signing requirement. It does not contradict any annotation. Minor deduction for slight redundancy (e.g., mentioning TronGrid endpoint twice).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose, spanning multiple paragraphs with technical minutiae (e.g., protobuf decoding, contract addresses, endpoint details). While informative, it could be streamlined to a concise overview (e.g., 'Builds unsigned LiFi cross-chain swap from TRON. Requires paired Ledger and prior approve for TRC-20.') without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, cross-chain mechanics), the description covers all critical aspects: prerequisites, signing flow, bridge protocols, validation steps, error conditions (allowance revert), and output (unsigned tx). It is comprehensive enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description enriches every parameter with actionable details: wallet mentions pairing, fromToken explains 'native' and approve, fromAmount clarifies base units, toChain enumerates options and bridge selection, toAddress warns about source wallet incompatibility, and slippage defines basis points and default. This exceeds what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Build an unsigned LiFi-routed cross-chain bridge with TRON as the source chain.' It names the specific action (build unsigned tx), resource (LiFi cross-chain bridge), and context (TRON source). This clearly distinguishes it from sibling tools like prepare_solana_lifi_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides thorough guidance: it specifies when to use (cross-chain bridging from TRON), prerequisites (pair Ledger via pair_ledger_tron, approve TRC-20 if needed), and important steps (blind signing, broadcast via TronGrid). It also warns about insufficient allowance and mentions the allowlist for NEAR Intents, leaving little ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint, idempotentHint), the description explains that the Ledger device retains the policy HMAC, the tool only forgets local entry, and idempotency with `removed: false` response. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear front-loading: purpose first, then behavioral context, then usage guidance. Every sentence adds value, though slightly verbose; could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, Ledger behavior, usage scenarios, and idempotency. Lacks explicit output format details, but description hints at return value. Adequate for a simple tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description of walletName, covering idempotency and HMAC retention. The main description does not add new parameter-specific information beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Drop a registered multi-sig wallet from the local cache.' It uses specific verb (drop) and resource (BTC multisig wallet), distinguishing it from siblings like register_btc_multisig_wallet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'call it before re-registering with different cosigners under the same name, or to clean up wallets you no longer use.' Also explains the device's HMAC retention, setting expectations for re-registration behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behaviors beyond annotations, including persistence details, unsigned mode behavior, duplicate handling, and chain support limitations. Annotations only provide idempotentHint, but the description adds crucial context for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured, starting with the core action and then detailing modes. It is information-dense but not bloated; every section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is remarkably complete given the tool's complexity (6 parameters, no output schema). It covers all modes, return signatures, constraints, and integration points with prepare flows, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, providing a baseline of 3. The description adds macro context that clarifies parameter roles (e.g., intendedChains for defense-in-depth), justifying a slightly higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Save a label → address binding to the address book.' It distinguishes from siblings like remove_contact and list_contacts by specifying this is for adding entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool across three modes (production+ledger, production no ledger, demo) and how it integrates with send flows. However, it does not explicitly contrast with alternatives like remove_contact or verify_contacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as READ-ONLY, explains the process of walking the pairing cache, fanning out to the indexer, and skipping empty addresses. This adds context beyond the annotations (readOnlyHint, idempotentHint) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise for the level of detail, starting with a clear header. While some sentences could be shorter, each adds value. It is well-structured and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the lack of an output schema, the description fully explains the return format (rolled-up totals and per-address breakdown with type, chain, index). It also covers prerequisites, alternatives, and edge cases, making it complete for this complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `accountIndex` has 100% schema description coverage. The schema description already explains its role and relation to pairing. The tool description reiterates similar context but does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sums the on-chain balance across cached USED addresses for a specific Ledger Bitcoin account index. It distinguishes itself from other balance tools by specifying the use of pairing cache and per-address breakdown, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions for when to use this tool, when to call `rescan_btc_account` for stale cache, and when to re-run `pair_ledger_btc` for gap-limit extension. This guides the agent effectively on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reinforces read-only nature from annotations ('READ-ONLY'). Adds details about data source (bitcoind), specific fields, and integration with get_market_incident_status. Requires configuration, which is not in annotations. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, densely packed with useful information. Every sentence contributes distinct value (purpose, alternative comparison, usage context, config requirement, issue references). Could be slightly more structured but remains highly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and annotations present, the description covers all necessary aspects: what it returns, how it differs from alternatives, required configuration, and its role in the broader system (used by get_market_incident_status). Completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description implicitly confirms parameterless call by listing output fields, adding no confusion. Baseline 4 for well-covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it returns bitcoind getmempoolinfo output with specific fields (tx count, bytes, memory, feerate, fees). Distinguished from Esplora's mempool view by emphasizing it provides the 'real local view' and daemon admission policy. Also notes usage by get_market_incident_status for mempool anomaly detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly indicates when to use: for the real local mempool summary from bitcoind RPC. Contrasts with Esplora's view, implying this is the authoritative source. Explicitly requires BITCOIN_RPC_URL configuration, setting a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral details: proxy following logic, cache, size cap, sanitization, and response structure, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core purpose, then detailed behavior. While somewhat long, every sentence adds value and is well-structured for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully explains response shape including edge cases (proxy, unverified). Covers error handling and context for all parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds context for followProxy behavior and explains response fields like abiSource and proxyFollowSkippedReason, providing extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a verified contract's ABI on supported EVM chains, explicitly distinguishes itself from generic WebFetch and sibling tools like check_contract_security and prepare_custom_call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to prefer this tool over generic WebFetch for ABI lookups, explains when proxy following is applied, and what to do for unverified contracts (ask user to paste ABI).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds the context of being a mirror and the need for configuration, but does not significantly expand on behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the read-only nature and providing essential context without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the source and dependencies, but given no output schema, it could elaborate on the return structure. However, it suffices for a simple, parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to add parameter info, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves litecoind getmempoolinfo output, and explicitly notes it is a mirror of get_btc_mempool_summary for LTC, providing a specific verb+resource and differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly requires LITECOIN_RPC_URL configured and points to the alternative BTC version, giving clear guidance on when to use this tool versus its BTC counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provided readOnlyHint and idempotentHint. The description adds behavioral context: the handle's 15-minute in-memory lifetime and that the response matches the original prepare_* call exactly, which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose, usage guidance, and behavioral note. No wasted words, and the critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers purpose, usage context, constraints, and behavior. It does not detail output shape but states it matches original prepare_* call, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is detailed, adding value beyond the schema. The description also adds the 15-minute lifetime context, enhancing understanding of handle usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool re-emits the prepared-tx JSON and VERIFY-BEFORE-SIGNING block for a known handle, distinguishing it from sibling prepare_* tools that create these entities. It specifies the exact resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use (when original prepare_* output drops from context) and when not to (NEVER recover from disk), providing an alternative (call this tool instead). Also mentions the 15-minute in-memory lifetime.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing it as safe and idempotent. The description adds significant value by detailing what files are read (~/.vaultpilot-mcp/config.json + env vars), that no RPC calls are made, and how agents should handle the setupHints and demoMode fields. This goes well beyond 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose but well-structured with clear sections (AGENT BEHAVIOR for setupHints, AGENT BEHAVIOR for demoMode). It front-loads the core purpose but includes many details that are necessary for agent guidance. Could be slightly more concise, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (no output schema, multiple return fields), the description is remarkably complete. It explains what fields are returned, how to interpret setupHints and demoMode, and even provides agent behavior instructions. The annotations (readOnlyHint, idempotentHint) further enhance completeness. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the guidelines. The description does not need to add parameter meaning but compensates by thoroughly describing the output structure, which aids in understanding the tool's use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only tool that reports the server's local config status without revealing secrets. It specifies the exact fields returned (config path, server version, RPC source classification, API key presence, Ledger account counts, WC session-topic suffix, preflight skill state, setupHints, demoMode). This is a specific verb-resource combination that distinguishes it from sibling tools like get_ledger_status and get_demo_wallet, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: 'Use this when the user asks 'is my config set up correctly' or 'why is my Solana balance read failing' before suggesting they re-run setup or paste keys.' It also explains the tool's scope (pure local I/O, no network calls). However, it does not explicitly state when not to use it or compare to alternatives, missing some depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already setting readOnlyHint and idempotentHint, the description adds context: it's an in-memory lookup with a 15-minute lifetime, deliberately omits certain outputs to prevent echo, and is read-only. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but is informative and front-loaded with the main purpose. It could benefit from better structure (e.g., bullet points) but is not overly verbose for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, and no output schema, the description fully covers what is included, omitted, the intended use case, lifespan, and error checks. It provides sufficient context for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'handle' is described in the input schema as 'Opaque handle returned by any prepare_* tool.' This adds meaning, but the overall description doesn't provide additional detail about the parameter beyond what the schema already states. Since schema coverage is 100%, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool returns a sparse verification artifact for a prepared tx, listing exact contents like raw calldata, chain, to/value, payloadHash, and preSignHash. It clearly differentiates from sibling tools by emphasizing adversarial independent verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it: after any prepare_* tool for adversarial independent verification, with a second LLM session. It also states when not to rely on it (disagreement or preSignHash mismatch) and that it's read-only with no external API calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds valuable context: APR estimate assumptions, best-effort nature, and that candidates have 0% APR. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with front-loaded purpose, efficient sentences, and no fluff. Every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the main output: ranked list of witnesses with APR info, and for address parameter, additional vote fields. It implicitly describes the structure but could explicitly mention the response is an array of witness objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The overall description reinforces the usage of the address parameter to retrieve vote allocation data for preparing votes, adding marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'TRON Super Representatives (SRs) + SR candidates', with explicit ranking by total vote count. It distinguishes from sibling tools like 'list_solana_validators' and mentions its relation to 'prepare_tron_vote' when the address parameter is used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the address parameter (to diff vote allocation before voting) and the default behavior (top-27 only, with optional candidate inclusion). It also notes APR limitations, but does not explicitly state when not to use the tool or list alternatives beyond the implied prefatory role to voting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral details beyond annotations: source-side scope (segwit/taproot only), that LiFi auctions routes, the PSBT contains specific outputs (vault deposit, OP_RETURN, change, fee), Ledger app clearsigns (no blind sign), verification block contents, and server-side checks. This fully informs the agent of the tool's behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs covering purpose, process, and verification. It is front-loaded with the most essential information. While lengthy, every sentence adds value. Minor improvement could be tightening some phrasing, but overall it is concise given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the return value (PSBT with 15-min handle) and the verification block details. It covers all necessary aspects: dependencies (LiFi, Ledger), constraints (source address type, destination chains), and failure conditions (TRON rejection). The agent has enough information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter clearly documented. The tool description adds overarching context such as 'multi-source consolidation is out of scope' and explains why 'max' is not supported for amount. While per-parameter details are already in schema, the description enhances understanding of how parameters interact in the broader workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'build' and the resource 'unsigned Bitcoin PSBT-v0' with the specific purpose of bridging native BTC to a token on another chain via LiFi's aggregator. It distinguishes itself from sibling tools like prepare_btc_send by emphasizing the cross-chain bridge aspect and explicitly listing supported destinations while rejecting TRON.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool returns a 15-min handle that should be forwarded to send_transaction, indicating the workflow. It also specifies which chains are supported and that TRON is rejected. However, it does not explicitly mention when not to use this tool versus alternatives like prepare_btc_send for simple sends, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true, but the description adds critical context: funding includes rent-exempt seed, authority is user's wallet (no handoff), blind-sign default on Ledger, deterministic address derivation. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense paragraph, front-loaded with main purpose, then details. Each sentence contributes info, but could benefit from better structure (e.g., bullet points). Efficient, but slightly packed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers most aspects (funding, authority, nonce, refusal, blind-sign, validator selection) but lacks output format description (e.g., what the unsigned tx looks like) and post-processing steps (sign and send via other tools). For a complex tool, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the description adds valuable nuance: wallet must have durable nonce and enough SOL for stake + rent + fee, validator is vote account (not identity), amountSol includes rent-exempt. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Build an unsigned native-stake-program tx'), the resource ('fresh stake account'), and the action ('creates... and delegates'). It distinguishes itself from sibling tools like prepare_native_stake_deactivate and prepare_native_stake_withdraw by mentioning the refusal logic when a stake account already exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (initial delegation), when not to (if stake account exists, use deactivate/withdraw), and prerequisites (durable nonce required, wallet must have enough SOL, call list_solana_validators first). Provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate `destructiveHint: true` and `idempotentHint: true`. The description adds context about the burn-address gate, the `BURN_ADDRESS_UNLIMITED_APPROVAL` error, and the friendly label resolution. It does not contradict annotations. However, it does not explicitly state that the output is an unsigned transaction needing submission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long (around 10 sentences) but every sentence provides unique value. It starts with the core purpose, then covers amount nuances, burn-address guard, friendly labels, EVM restriction, and usage alternatives. Though dense, it could be slightly more streamlined but remains well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, no output schema, many siblings), the description covers purpose, parameter details, validation, and usage guidance. It lacks explicit mention that the output is an unsigned transaction requiring `send_transaction`. With no output schema, this is a minor gap. Overall, it provides comprehensive context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, but the description adds critical semantics: `amount` clarifies decimal vs raw units and accepts 'max'; `spender` is described as typically a protocol contract; `token` warns against wrappers; `acknowledgeBurnApproval` explains its guard purpose; `wallet` requires pairing; `chain` has enum. This goes well beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned ERC-20 approve transaction, explicitly contrasts with `prepare_revoke_approval`, and restricts to EVM chains. It distinguishes from protocol-specific prepare tools, making the purpose and scope precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises preferring protocol-specific prepare tools (e.g., `prepare_aave_supply`) when approval is bundled, and reserves this tool for one-off allowance-setting. It also specifies EVM-only and explains when to use `acknowledgeBurnApproval`. This leaves no ambiguity about appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true; description adds that it builds an unsigned transaction, requires send_transaction, and that freezing alone does not accrue rewards. No contradictions. Describes return type (preview + opaque handle) but lacks details on the return structure, which is acceptable given 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: starts with core purpose, then caveats, alternatives, and integration steps. Every sentence is informative and non-redundant. Efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main action, rewards context, lock-up period, and related tools. Lacks specifics on the preview format and error cases, but overall sufficient for a complex staking tool. No output schema, so description could be more detailed, but it remains helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are documented in the schema (100% coverage). Description adds value by clarifying that amount is a human-readable decimal converted to SUN internally, resource enum meanings, and the from address prefix T. Extra context beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned TRON Stake 2.0 FreezeBalanceV2 transaction, specifying the action (freeze), resource (TRX), and outcomes (earn bandwidth/energy, gain voting power). It distinguishes from siblings like prepare_tron_vote and prepare_tron_unfreeze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to earn bandwidth/energy and voting power), what not to expect (no rewards without voting), and references related tools (list_tron_witnesses, prepare_tron_vote, prepare_tron_unfreeze, prepare_tron_withdraw_expire_unfreeze). Also mentions the 14-day cooldown for unlocking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, idempotent. The description adds detailed behavioral traits: privacy guard regex scan, redaction error, rounding percentages, read-only nature, no signing/broadcast. This far exceeds annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear separation of purpose, usage, privacy guard, and version notes. While slightly lengthy, every sentence contributes meaningful information, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, privacy concerns, and lack of output schema), the description adequately covers all necessary context: what the output is (jsonString), how it's used, privacy protections, rounding behavior, and version limitations. It feels complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 9 parameters described. The description adds value by clarifying required address groups, free-form fields subject to redaction, and the role of 'name'. It provides useful context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it generates a shareable, anonymized JSON snapshot of portfolio structure with clear exclusions (no addresses, USD values, hashes). It distinguishes from sibling tools like import_strategy by explaining the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this when the user wants to share their setup' and explains the recipient workflow. It lacks explicit when-not-to-use scenarios but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint and idempotentHint, but description adds critical behavior: BIP-137 scheme, return of signature+messageSha256, drainer-string refusal before device interaction, and Taproot refusal. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense but well-structured, front-loading purpose. Could be slightly streamlined but effectively communicates key points without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return values, UX, refusal conditions, and wallet constraints. References sibling tool. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. Description adds value by confirming wallet must be paired, reiterating Taproot refusal, and providing context on message encoding and prefix. Adds beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool signs a UTF-8 message with a paired Litecoin address using BIP-137, specifying the prefix, return values, and linking to sibling sign_message_btc for UX similarity. It distinguishes by coin and refusal of Taproot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is signing Litecoin messages. It provides conditions for refusal (drainer strings, Taproot) and mentions same UX as BTC sibling, but lacks explicit alternative or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds substantial behavioral context: 'One USB round-trip; never throws — surfaces every failure as a structured verdict', the exact APDU command, and the mode requirement. This goes well beyond 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but efficiently packed. It front-loads the key purpose and then provides necessary details in a logical order. Every sentence adds value, though some internal details (like the full APDU command) could be considered extraneous for usage decisions, but they still enhance transparency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 explain return values, which it does exhaustively (seven structured verdicts). It also covers prerequisites, mode requirements, and error conditions. For a tool with no parameters and no output schema, this is exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is trivially 100%. The description adds meaning by explaining what data is checked and the possible return values, but since there are no parameters to document, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'READ-ONLY firmware-pinning check' that reads firmware version and asserts against a manifest. It distinguishes itself from siblings like get_ledger_device_info or verify_ledger_attestation by detailing its exact purpose and structured outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a critical prerequisite: 'REQUIRES the device to be in DASHBOARD MODE — no app open. Ask the user to close every Ledger app...' It also explains that opening an app will result in a 'wrong-mode' verdict. However, it does not explicitly name alternative tools or conditions when not to use this tool, which would have earned a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description details output format, sorting, null handling for TVL and riskScore, filtering behavior, and edge cases like empty results. It also explains v1 coverage gaps and agent constraints (do not pick), providing significant additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, starting with purpose, then detailing coverage, output, filters, and agent behavior. Every sentence serves a purpose, though the coverage gap explanation could be more succinct. It remains effectively scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema), the description is exceptionally complete: it explains all parameter behaviors, output format, sorting, null handling, and agent usage constraints. It fully compensates for the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by explaining meta-asset 'stables', resolution rules (ETH→WETH), default chain behavior, and the nuanced filtering of null values for minTvlUsd and riskCeiling. This exceeds the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a ranked table of supply-side yield opportunities for a given asset across integrated lending/staking protocols. It specifies covered protocols, output fields, sorting, and filters, distinguishing it from sibling tools that handle individual protocols or positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly differentiates this tool from others by emphasizing it surfaces data rather than recommending actions, but it does not explicitly compare to sibling tools like get_protocol_risk_score or individual protocol yield tools. It provides clear filter guidance and agent behavior constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, destructive=false, idempotent, open world. The description adds that it uses current APRs, is forward-looking, returns specific fields (protocol, input amount, APR, projected rewards), and emphasizes no on-chain position reading. This adds significant behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, all essential, with purpose upfront. No fluff or redundancy. It efficiently conveys purpose, usage context, output, and limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, query). Description mentions return values explicitly despite no output schema, and provides sufficient context with annotations covering safety and idempotency. It also informs about pairing with a sibling tool for actual holdings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for both parameters (protocol enum and amount with examples). The description does not add new semantic information about parameters beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool projects annual yield on a hypothetical staking amount for Lido or EigenLayer using current APRs. It distinguishes itself from sibling tools by explicitly noting it is forward-looking and does not read on-chain positions, and recommends pairing with get_staking_positions for actual holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use: 'for 'what would I earn if I staked X ETH?' questions before the user commits capital.' It also clarifies what it does not do (no wallet reading) and suggests a complementary tool (get_staking_positions), giving clear boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces these (stateless/read-only, does not change demo state) and adds behavioral context: response is verbose, presumes intent, and agent should not call as probe. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and bullet-like flow. However, it is somewhat verbose with some repetition (e.g., 'stateless / read-only' appears twice). Still, every sentence adds value and it's appropriately detailed for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains return value (tailored decision tree, no-op outside demo mode). Covers all parameters with usage context, preconditions, agent behavior, and edge cases. Nothing missing for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant context: hasLedger controls deferral, hasRunSetup skips setup walkthrough, chains drives RPC key recommendations, acquireKeys affects recommendation tone. This goes well beyond the brief schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a step-by-step guide for exiting demo mode. It specifies the output is a tailored decision tree, distinguishes itself from other tools by being stateless/read-only, and the sibling list contains no similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (only after user confirmation of intent), provides pre-call questions (hasLedger, hasRunSetup, chains, acquireKeys), and when not to call (as a probe). Also covers edge cases: deferral if no Ledger, no-op outside demo mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, destructive, idempotent, openWorld hints. Description adds helpful context: uses mempool.space API, configurable via env var, and that testnet/signet are rejected. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with essential information front-loaded. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple read-only tool with full annotations and one parameter. Covers purpose, behavior, configuration, limitations, and expected output components.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers address parameter completely (100% coverage). Description reinforces address types and adds behavioral constraint ('Phase 1 is mainnet-only'), which adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches confirmed + mempool balance for a single Bitcoin mainnet address, lists returned data components, and differentiates from other get_btc_* tools by specifying single address. Includes address type restrictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says READ-ONLY, mentions mainnet-only limitation, and describes backend. Does not explicitly contrast with sibling tools like get_btc_account_balance, but the single-address scope is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, describes indexer dependency (mempool.space default, configurable via env var or user-config), conditional availability of BIP-113 and difficulty fields, and normal block gap behavior. Adds significant operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value. Front-loaded with core purpose and read-only flag. Followed by return fields, configuration detail, then use cases. No fluff, well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all relevant aspects: what the tool does, what it returns, how it's configured, and appropriate use cases. With no output schema, the description fully explains return values. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds meaning by listing return fields and their types (e.g., 64-hex hash, unix seconds) which compensates for lack of output schema. Baseline 4 for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it is READ-ONLY and returns the current Bitcoin mainnet chain tip. Lists specific return fields (height, hash, timestamp, ageSeconds, BIP-113 median time past, difficulty). Clear verb+resource, distinct from sibling tools by focusing on the single latest block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: latest-hash lookups, block-age UX context, indexer-freshness checks, confirmation-depth math. Also explains Poisson block intervals. Does not explicitly exclude alternatives, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by revealing that the tool returns available: false with a setup hint when RPC is not configured. It also confirms the read-only nature and idempotency. No contradictions with annotations; in fact, the description enriches the behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise yet comprehensive. It front-loads the read-only nature and includes key output details, use case, RPC requirement, and fallback behavior. Every sentence adds value, and the references to issues #248/#233 v2 are minor but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains what the tool returns (branchlen, status with possible values) and covers the edge case of missing RPC configuration. It also explains why this data is unique (cannot be obtained from Esplora). For a zero-parameter tool, this is exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty with 100% coverage. The description does not need to add parameter information. According to guidelines, baseline for 0 params is 4, so this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning bitcoind's getchaintips output, listing forks with branchlen and status. It explicitly states its purpose for fork/deep-reorg detection and distinguishes itself from Esplora indexers, which cannot expose this data. The verb 'get' and resource 'BTC chain tips' are clear, and it differentiates from sibling tools like get_ltc_chain_tips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that this is the primitive for fork/deep-reorg detection and notes that Esplora cannot provide this data. It also specifies the requirement for BITCOIN_RPC_URL and mentions the fallback behavior when RPC is not configured. While it could mention alternatives like get_btc_block_tip, the context is sufficient for an agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent, openWorld. Description adds useful context about confidence field and non-predictive nature, but doesn't add new behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded with purpose. Slightly verbose but all content is justified and adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Very complete given complexity: explains two modes, allowlist details, return fields (though no output schema), and agent behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage. Description adds meaning: explains two input modes, allowlist, and escape hatch, providing context beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches USD price by ticker or CoinGecko ID. Distinguishes from sibling tool `get_token_price` for non-EVM assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly when to use (for non-EVM assets) and when not to (for EVM tokens, use `get_token_price`). Also provides scope (snapshot, not forecast) and agent behavior guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm read-only, non-destructive, idempotent behavior. The description adds critical context: parallel fan-out, per-protocol failure handling via notes field, guarantee that missing protocols are never silently wrong, and return field details (e.g., marginToLiquidation). No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence adds value. It front-loads the core purpose and then structures details logically. The historical note (#427) is slightly meta but informative. Slightly longer than minimal but well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists all returned fields (protocol, chain, market, healthFactor, collateralUsd, debtUsd, marginToLiquidation). It covers parameter constraints, error behavior, and cross-protocol scope, making it fully self-contained for a read-only health check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description fully compensates by explaining wallet (EVM), solanaWallet (Solana), threshold (default 1.5, range implied), and the required at-least-one condition. This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a cross-protocol liquidation-risk check, listing specific EVM and Solana protocols. It explicitly mentions the verb 'check' and the resource 'health alerts', and distinguishes from per-protocol position tools like get_compound_positions or get_kamino_positions by aggregating across protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires at least one of wallet or solanaWallet, and explains partial results on failures. However, it does not explicitly state when to use this tool over individual protocol position checkers, though the cross-protocol scope is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description says 'Read-only' and describes a non-destructive operation. It adds context beyond annotations: data source (Reservoir), EVM-only constraint, and return field details. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first lists return fields, second gives use case and source, third states constraints. It is front-loaded with key information and contains no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description enumerates return fields thoroughly (name, symbol, image, description, floor ask, top bid, volume windows, owner count, total supply, royalty). It also specifies data source (Reservoir) and constraints (EVM-only, chain default). For a read-only lookup tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both parameters are well-described in the schema. The description adds minor reinforcement: 'Pass the contract address on its deployed chain (defaults to ethereum).' This does not significantly expand semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves NFT collection metadata including specific fields like name, symbol, image, floor ask, top bid, volume windows, owner count, total supply, and royalty. It distinguishes from siblings by indicating 'Wallet-less' and 'vitals' lookup, and explicitly notes EVM-only vs Solana.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use for 'what's this collection's vitals?' lookups before adding to a watchlist or evaluating exposure. It also states EVM-only in v1 and defers Solana NFTs to a different API, helping agents avoid incorrect usage. Pass contract address and default chain are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent. Description adds behavioral details: requires API key authentication, returns pending and recently-executed transactions, risk notes, and union/dedup behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and well-structured, but somewhat dense. Every sentence earns its place with no redundancy, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately covers return structure (threshold, owners, version, balance, transactions, risk notes). Also mentions prerequisites (API key), limitations (no ERC-20), and cross-references related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description fully explains each parameter: signerAddress for wallet discovery, safeAddress for direct lookup, chains with default ethereum and supported values. Adds meaning beyond schema patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches Safe multisig accounts for an EVM owner address and/or by Safe address, listing returned fields. Distinguishes from siblings by explicitly noting ERC-20 balances are not included and directing to get_token_balance or get_portfolio_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use signerAddress (discover all Safes for a wallet) vs safeAddress (look up one Safe), and that both can be used together. Describes chains default behavior and requirement for SAFE_API_KEY, also notes what the tool does not cover (ERC-20 balances) with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent. Description adds: cheap chain-read, one getAccountInfo per PDA, no SDK load, no oracle fetch, never throws, returns empty arrays for empty wallet. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (~100 words), front-loaded with 'READ-ONLY' and purpose. Structured with usage guidance, technical details, and edge cases. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description fully explains return values (durable-nonce fields, MarginfiAccount PDAs) and edge case (empty wallet). Covers all context needed for a single-parameter read-only probe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter wallet has a detailed schema description covering format and return info. Tool description adds little beyond stating it probes setup pieces; schema already provides value. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it probes Solana wallet setup pieces (durable-nonce and MarginfiAccount PDAs). It uses specific verbs and resource references, and distinguishes itself from siblings by mirroring get_ledger_status pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling before multi-step Solana flows to skip redundant prepare_* calls. Provides concrete scenario and alternative (avoid re-proposing). Clear when and why to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds specifics: the error when no deposit exists, health-factor gating on-chain, requirement of a durable nonce, and same blind-sign treatment as prepare_kamino_supply. No contradictions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, each sentence adds value (purpose, error condition, health gate and nonce requirement). No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's nature (building a transaction with 3 required params), the description covers purpose, error handling, health-factor constraint, nonce requirement, and signing treatment. It references the sibling for consistency. No output schema, but the description adequately sets expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the durable nonce requirement, which is not in the schema. While the schema already describes each parameter, the description provides additional behavioral context beyond parameter-specific details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'build a Kamino withdraw tx' and the resource 'Kamino withdraw', explaining it pulls liquidity from a previously-supplied reserve. It distinguishes from siblings by referencing prepare_kamino_supply and noting the error condition if no deposit exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to withdraw liquidity) and provides context about error conditions and health-factor gating. However, it does not explicitly compare to alternatives like borrowing or repaying, though the tool name and sibling set make this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: transaction is unsigned, uses marinade.deposit, no ephemeral keypair, ATA auto-created with reclaimable rent, durable nonce required, blind-sign on Ledger. No contradiction with annotations (destructiveHint=true, readOnlyHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief yet comprehensive: three sentences covering purpose, key behavioral details, and prerequisites. No redundant information; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (durable nonce, Ledger blind-sign, ATA rent) and no output schema, the description covers all essential aspects: operation, prerequisites, side effects, and user actions. Completely informs the agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context: wallet funds deposit and receives mSOL, requires nonce init and enough SOL for rent+tx fee; amountSol is human-readable with rounding. This complements the schema effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned Marinade stake transaction, depositing SOL and receiving mSOL. It uses specific verb 'deposit' and resource 'SOL into Marinade', distinguishing it from sibling staking tools like prepare_jito_stake and prepare_lido_stake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires a durable nonce via prepare_solana_nonce_init, warns about blind-sign on Ledger, and mentions automatic ATA creation. While it lacks explicit when-not-to-use or alternative tools, the prerequisites and wallet setup conditions are clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations: discloses that an ERC-20 approve tx may be emitted first, explains approvalCap behavior, and mentions returns a handle+preview for Ledger signing. No contradiction with annotations (destructiveHint=true consistent with write).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-structured sentences with key info front-loaded. No redundancy; every sentence adds value. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects for a transaction-building tool. Lacks explicit mention of return value shape (only mentions 'handle + preview'), but sufficient given no output schema and many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: clarifies amount is human-readable (not wei), 'max' for full balance, and provides detailed guidance on approvalCap options. Schema coverage is 100%, but description enhances usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned Morpho Blue supply transaction, depositing the market's loan token to earn lending yield. It distinguishes from sibling tools like prepare_morpho_borrow by specifying supply verb and market context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (supply to Morpho Blue), mentions prerequisite allowance handling and chain limitation (only ethereum). Lacks explicit exclusions or alternatives, but adequate for selection among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds critical details: the one-epoch cooldown, no rewards during deactivation, requirement for durable nonce, same Ledger-blind-sign treatment as delegate, and that the on-chain program reverts if already deactivating but the simulation gate catches it. These enrich the agent's understanding significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the core action, then adds essential details in concise sentences. Every sentence provides value (timeline, prerequisites, error handling, next steps). No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of staking deactivation (timing, authority, nonce, sibling tools), the description covers all necessary context: prerequisites, behavior, failure modes, and subsequent step. No output schema exists, but the tool's output (unsigned tx) is implied and sufficient. The description is complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameter descriptions already explain the purpose and constraints. The description repeats some of that information but does not add new meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Build an unsigned native-stake deactivate tx' and the resource (native stake deactivation). It distinguishes from siblings by referencing prepare_native_stake_withdraw for the next step and comparing Ledger handling to prepare_native_stake_delegate. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit guidance: use when stake is active and not already deactivating/inactive; prerequisites (wallet must be staker authority, durable nonce required); when not to use (already deactivating leads to revert, caught by simulation). It explicitly mentions the alternative tool to use after cooldown (prepare_native_stake_withdraw).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Exceeds annotations by detailing the two instructions (nonceAdvance and nonceWithdraw), the exact balance returned, and the refusal condition for subsequent sends.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding essential context, but slightly verbose for a single-parameter tool. Still efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers preconditions, transaction structure, post-effects, and error case (refuses if no nonce). No gaps given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema: specifies the exact SOL amount returned and confirms the balance goes to the same wallet, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tears down a durable-nonce account and returns its balance, with specific verb and resource. It distinguishes from siblings like prepare_solana_nonce_init.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context: closes nonce account and warns about post-broadcast behavior, but no explicit when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and idempotent behavior; description adds critical context: atomic replacement, TRON Power constraint, reward accrual per block, and that output is a preview+handle for Ledger signing via send_transaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and critical warnings. Slightly long (107 words) but each sentence serves a purpose; no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key aspects: operation, prerequisites (availableTRONPower), atomic behavior, output (preview+handle), and next step (send_transaction). No output schema, but description mentions output nature, making it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents parameters with 100% coverage; description adds valuable nuance for 'votes' (must be full allocation, sum constraint) and 'from' (address format), enhancing usability beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it builds an unsigned TRON VoteWitnessContract transaction to cast votes for Super Representatives, using precise verbs and resources, and distinguishes from sibling tools like prepare_tron_claim_rewards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance, explains atomic replacement of prior votes, warns about not passing deltas, recommends checking availableVotes via list_tron_witnesses, and mentions reward harvesting via prepare_tron_claim_rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true. The description goes beyond by detailing the exact sequence of operations (decreaseLiquidity, collect, optional burn, mint), slippage applied independently to close and re-deposit phases, approval chaining, and hard refusals. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but efficiently packed. It front-loads the core purpose and then adds behavioral specifics. Some sentences are dense but still clear. Could be slightly more structured (e.g., use bullet points for the composition sequence), but overall concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema, the description covers the operation's behavior, preconditions, and parameter nuances thoroughly. It explains the transaction flow, slippage handling, and approval needs. However, it does not describe the return type or structure of the unsigned transaction, which could be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, but the description adds meaningful context for key parameters like slippageBps (explains effective 2x tolerance), burnOld (explains default behavior and rationale), and approvalCap (explains options). For parameters without schema descriptions, the tool name and context provide some hints, but more could be added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned Uniswap V3 LP rebalance transaction, moving a position from its current tick range to a new one in a single multicall. It distinguishes from sibling tools like prepare_uniswap_v3_mint or prepare_uniswap_v3_decrease_liquidity by specifying the rebalance operation and the multicall composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to rebalance a position) and explicitly lists hard refusals: owner mismatch, mis-aligned new ticks, identical new range, zero-liquidity position. It also implies when not to use it (e.g., for simple liquidity adjustments), providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds rich context: retries transient errors, bounded parallel requests, pure indexer-side, and details the three-state return signal (needsExtend, unverifiedChains). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that efficiently covers purpose, usage, state signals, and limitations without wasted words. Structurally front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (rescan, indexer, state signals), annotations, and thorough input schema, the description is complete. It explains the return behavior (three-state signal), rate limits, and retry logic, compensating for the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with a detailed parameter description in the input schema. The tool description does not add new information about the parameter beyond what is already in the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'refresh' and the resource 'cached on-chain txCount for every paired Bitcoin address under one Ledger account', clearly distinguishing it from siblings like pair_ledger_btc (initial pairing) and get_btc_account_balance (reading cache).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use ('after user has received funds' or 'indexer was stale at original scan time'), clarifies no Ledger/USB interaction, and explains the three-state extend signal to guide next actions (re-run vs. re-pair), providing explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and no destructiveness; description adds valuable context: retries on transient errors, parallelism bounded to LITECOIN_INDEXER_PARALLELISM, three-state extend signal, and no Ledger interaction. Slightly verbose but no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections but is slightly repetitive (e.g., 'Pure indexer-side: NO Ledger / USB interaction' appears twice). Still, every sentence adds value and it's easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the three-state extend signal, indexer behavior (parallelism, retries), and when to use alternative tools. Covers all necessary context for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant meaning beyond schema: explains the return signals (needsExtend, unverifiedChains), that it updates persisted cache, and the use case for accountIndex. Parameter description in schema is also detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'READ-ONLY — refresh the cached on-chain `txCount` for every paired Litecoin address under one Ledger account by re-querying the indexer,' clearly stating the verb and resource, and distinguishes itself from siblings like rescan_btc_account and pair_ledger_ltc by specifying Litecoin and indexer-side operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'after the user has received funds (so a previously-empty cached address now has history) or when the indexer was stale at the original `pair_ledger_ltc` scan time.' Also provides exclusions: 'Pure indexer-side: NO Ledger / USB interaction,' and alternatives (re-run pair_ledger_ltc for needsExtend, re-run rescan for unverifiedChains).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: it upgrades demo mode from default to live, affects tools like prepare_* and send_transaction, describes per-cell replacement semantics, and clarifies that empty args clear the wallet. No contradictions with annotations (idempotentHint=true matches replace behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and well-structured with numbered lists for input shapes. It is slightly verbose but every sentence adds value. Front-loading the core purpose helps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three input shapes, demo mode behavior, side effects on other tools), the description is remarkably complete. It covers edge cases (null cells, no-op outside demo mode), clearing wallet, and the impact on other tool groups. No output schema is needed as behavior is fully described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value beyond schema: mutual exclusivity of parameter groups, examples for each shape, explanation of per-cell vs batch loading, and clarification of null cells. This fully compensates for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: switching the active demo wallet via three input shapes. It distinguishes itself from siblings like 'get_demo_wallet' and 'exit_demo_mode' by specifying its unique role in demo mode configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly limits usage to demo mode, explains the three input shapes with examples, and notes that calling outside demo mode returns a no-op. It could be enhanced by explicitly mentioning when to prefer alternatives like 'exit_demo_mode', but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses persistence (process memory only, not across restarts), security (URL rejection for prompt-injection), and idempotent nature beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but slightly verbose; however, all content is valuable and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately explains the side-effects (enables tools, persistence, agent behavior). Could mention return value briefly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of param, but description adds crucial details: bare key only, example, where to get, and security constraint (no URL).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Set' and resource 'Etherscan V2 API key' with specific purpose for EVM reads. Distinguishes from sibling like set_helius_api_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (demo-mode flow, enabling tools without restart), precedence over env var, and agent behavior (call immediately, never echo key).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true. The description adds significant behavioral context: it returns a base64 signature and messageSha256, refuses drainer strings before any device interaction, refuses taproot addresses with an explanation, and describes the on-device confirmation UX. No contradictions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the core purpose first, followed by details on messageSha256, UX, drainer refusal, and taproot refusal. While verbose, every sentence adds value and the structure helps readability. Minor reduction could improve conciseness but is not detrimental.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema; the description partially covers return fields (base64 signature and messageSha256) but does not specify exact output structure. Considering complexity (param details, refusal logic, UX), it is fairly complete. An explicit output field list would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds meaningful context: for 'wallet', it lists supported/refused address types and requires prior pairing; for 'message', it explains typical size, max length rationale, and UTF-8 encoding. This goes beyond the schema's basic constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: signing a UTF-8 message with a paired Bitcoin address using BIP-137, specifying the return format (base64 signature and messageSha256). It distinguishes itself from siblings by explicitly refusing taproot addresses and drainer strings, and mentions the on-device UX. This provides a specific verb and resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (for signing messages with Bitcoin addresses that are legacy, P2SH-wrapped, or native segwit) and when not to use (for taproot addresses or messages containing drainer strings). It provides an alternative: use a different paired address type. It also mentions that legitimate Sign-In-with-Bitcoin flows don't use the refused markers, guiding the agent on appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, etc. The description adds 'READ-ONLY', mentions the cap at 200, and discloses behavior about indexer-specific fields (mempool.space). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not verbose, front-loading the main purpose. Each sentence adds value, and it's well structured without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 covers input behavior, output fields, and use cases comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds meaning by explaining the default (144), cap (200), and rationale for the cap ('bound HTTP fan-out on free-tier indexers').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches recent Bitcoin block headers (newest-first) and enumerates the fields included. It distinguishes from siblings like get_btc_block_stats and get_btc_block_tip by specifying its purpose for chain-health questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides example questions ('is the chain producing blocks at the expected rate?') and notes internal use by get_market_incident_status. Does not explicitly state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description reveals the data source (mempool.space with fallback to Esplora) and the exact labels returned. This provides significant behavioral context that helps the agent understand reliability and fallback behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: purpose and unit, specific labels, and data source. Front-loaded with 'READ-ONLY' and clear verb. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers what the tool returns (five labels with meaning) and where the data comes from. An agent can confidently use the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters (schema coverage 100%), the description compensates by thoroughly explaining the output labels and their meanings, which is essential for interpreting results. Baseline for no parameters is 4, and the extra detail on return values and data source elevates it to 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides Bitcoin fee-rate recommendations in sat/vB, lists the five specific labels with their meanings (fastestFee, halfHourFee, etc.), and distinguishes itself from other BTC tools by focusing solely on fee estimates. No sibling tool duplicates this purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description does not explicitly state when not to use the tool or name alternatives, it clearly implies its use for obtaining Bitcoin fee recommendations. Given the uniqueness of this tool among siblings, explicit exclusions are not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds rich behavioral context: it uses the GET_APP_AND_VERSION APDU, works on dashboard or chain apps, lists example outputs for various apps, and describes the clean error behavior when no device is connected or udev rules are missing. No contradictions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the core purpose, then provides detailed examples and usage context. While it is lengthy, all information is valuable and well-organized. Could be slightly more concise but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return values (app name+version, hint, deviceConnected: false). It covers edge cases (no device, missing udev rules) and provides actionable instructions for the agent on how to interpret and use the information. Complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to add parameter information. The baseline is 4, and the description correctly omits param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool probes the connected Ledger device over USB HID and reports the currently open app (name and version) plus an actionable hint. It explicitly distinguishes from sibling tools like pair_ledger_solana by positioning this as a pre-check to enable context-aware instructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use: call BEFORE pair_ledger_solana/pair_ledger_tron. It provides examples of how the result can be used to inform the user. It also notes that the tool never throws and returns clean error states, so the agent knows it's safe to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds details about cached data, security (topic verification, spoofing risks), and peerUnreachable behavior. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but well-structured and front-loaded. Each sentence adds necessary context for security and correct usage. Slight verbosity justified by tool's critical role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully documents return format, field semantics, error conditions (peerUnreachable), and security workflow. Complete for a status tool with complex usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline is 4. Description does not need to add param info, and it adds no param semantics (none exist).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reports WalletConnect session status for EVM and cached pairings for TRON/Solana, distinguishing from sibling pairing tools. It specifies return fields and when to call it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to call first (for resolving wallet references), when not to ask for addresses, security verification steps, and handling peerUnreachable. References sibling tools and tells agent actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds substantial caveats: v1 limitations (capped history, gas not subtracted, Solana swap legs skipped, Bitcoin unsupported) and truncation flag when history caps. This goes beyond basic read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and well-structured, but slightly verbose. However, every sentence serves a purpose, and key info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers all necessary contextual info: what's included/excluded, period definitions, chain support, caveats, and truncation behavior. It is highly complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions. The description adds context like requiring at least one address and explaining the 'inception' period's 365-day cap. It adds value but the schema already handles param meaning well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: 'Wallet-level net PnL over a preset time window across EVM...' and provides a detailed mathematical formula. It distinguishes itself from the sibling `get_portfolio_diff` by noting when to pair them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('simple how much did I make?') and when to pair with `get_portfolio_diff` for decomposition. Also lists period options and required addressing at least one chain address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, safe behavior. Description adds extensive behavioral detail: breakdown into price moves, deposits/withdrawals, other; v1 caveats about truncation, interest accrual handling, Solana exclusions, Bitcoin limitations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose, then details parameters and caveats. Long but every sentence adds value. Could be slightly more concise, but acceptable for complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive given no output schema: explains return structure, parameter behavior, and limitations convincingly. Covers all necessary context for agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. Description adds extra context like 'at least one required', window rolling vs calendar, and format parameter purpose. Adds moderate value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it decomposes portfolio changes over time, specifies verb 'decompose' and resource 'portfolio changes', and explicitly distinguishes from siblings (get_portfolio_summary and get_pnl_summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: explains supported address types, window options, format control, and caveats about truncation. Differentiates from siblings, helping agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, openWorldHint. Description adds that it's a snapshot, EVM-only, and includes agent behavior constraints (not a pick tool). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and informative, but includes a minor reference to 'Issue #599' that adds little value. Otherwise clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input, alternatives, and scope well. Lacks explicit output format (e.g., number or object), but states it returns current spot USD price. Sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description explains 'native' vs contract address for token parameter and lists supported chains in schema. Adds examples for native assets per chain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches USD price via DefiLlama, specifies token as 'native' or ERC-20 address, and distinguishes from siblings (get_swap_quote for swaps, get_coin_price for non-EVM natives).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to prefer this tool over get_swap_quote and when to use get_coin_price for non-EVM natives. Also clarifies scope: current spot price, not a forecast or signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description reinforces these with 'READ-ONLY', 'Pure local introspection + cache read; no RPC, no fresh network call', and 'Never throws'. It also explains the heuristic nature, caching behavior, and potential caveats, adding significant context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal but well-structured: it starts with purpose, then lists return fields using backticks, and ends with agent behavior. Every sentence adds necessary context. Could be slightly more concise, but it remains clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description completely covers return values, their meanings, and how they are derived (heuristics + cache). It also includes agent behavior, edge cases (unknown installPath, unresolved version check), and operational constraints (no network call). This makes the tool fully understandable without needing external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so baseline is 3. However, the description adds substantial value by detailing the output fields (current, latest, updateAvailable, installPath, command, restartHint, note) and their semantics, which compensates for the lack of parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'READ-ONLY — return the recommended upgrade flow for the running install path', which is a specific verb-resource pair. It then explains exactly what the tool does: combines heuristics and cached state to return upgrade command, and distinguishes itself by clarifying it's a pure local read with no network call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool: 'when the user asks to upgrade, when the VAULTPILOT NOTICE — Update available block appears and the user wants to act on it, or when the user asks how do I update vaultpilot-mcp'. It also provides agent behavior instructions: 'Surface command to the user verbatim — do not execute it autonomously' and what to do if installPath is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, but the description adds crucial details: the exact return structure, that addresses are not re-surfaced, and that only hashed tokens are stored. This goes well beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, then parameter usage, then return details and pairing advice. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains what each returned object contains and what is omitted (addresses not surfaced). It also covers usage context and related actions, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 boolean parameter with 0% description coverage, but the description fully explains its effect: 'pass includeInactive: true to see history'. This adds complete meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists read-only share tokens the user has generated, with a specific verb and resource that distinguishes it from sibling tools like generate_readonly_link, import_readonly_token, and revoke_readonly_invite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains default behavior (active invites only) and optional parameter to see history, and suggests pairing with revoke_readonly_invite for invalidation. However, it does not explicitly state when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces this by emphasizing it is read-only, pulls a public feed, and includes important caveats like 'the MCP is NOT the source of truth' and verification steps. Adds significant behavioral context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured: front-loaded with purpose, then details, then workflow instructions. Every sentence serves a purpose, covering core functionality, defaults, usage order, and verification steps. Could be slightly more concise, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested filters, sorting, workflow dependency), the description is remarkably complete. It explains return columns, defaults, sort options, usage order, and even includes invariant notes and instructions in the response. Without an output schema, the description adequately covers the return values and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds context beyond schema by explaining default values (excludeDelinquent=true, excludeSuperminority=false) and clarifying sort behavior (e.g., `score` = wiz_score descending). This extra context justifies a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Read-only validator-ranking helper for prepare_native_stake_delegate', specific verb ('list'), resource ('Solana validators'), and distinguishes from sibling tools by noting its role as a prerequisite. It uniquely explains its purpose in the workflow, which differentiates it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'USE THIS BEFORE prepare_native_stake_delegate'. Provides detailed workflow instructions including verification steps (open stakewizUrl, byte-equality-check votePubkey). Also explains the benefit (surfacing a ranked menu instead of forcing user to leave). This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it reads the device address at m/44'/195'/<accountIndex>'/0/0, caches it for get_ledger_status, and is idempotent (calls for same index refresh in place). It also describes error behavior when the TRON app is not open or device locked, providing actionable error messages. Annotations indicate idempotentHint=true, which aligns with the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, REQUIREMENTS section, derivation path, and usage notes. It is slightly verbose (e.g., explaining derivation path in detail), but every sentence adds value. The information is front-loaded with the core action and requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers all necessary context: preconditions (device plugged, unlocked, Tron app open), behavior (reads address, caches), usage patterns (multi-call for accounts), error handling (actionable errors), and relation to other tools (must be called before prepare/send). It is comprehensive for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description of the accountIndex parameter (hardened BIP-44 index, default 0, multiple calls for different indices). The description adds context about the derivation path and caching behavior, which complements the schema. With 100% schema coverage, baseline is 3; the additional context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: pairing a directly-connected Ledger device for TRON signing via USB HID. It specifies the derivation path and caching behavior, and distinguishes this tool from siblings like pair_ledger_btc or pair_ledger_solana by focusing on the TRON app and USB HID interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: before any prepare_tron_* tool or send_transaction with a TRON handle. It also specifies that it does not work with WalletConnect due to CAIP namespace limitations, and instructs calling multiple times with different accountIndex values to pair additional accounts. This provides clear when/why-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations, including 15-min handle, verification block, coin-selection method, fee-cap guard, and RBF default. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with no wasted words. Each sentence serves a purpose, starting with core function and expanding on details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thoroughly covers inputs, behavior, and return values despite no output schema. All necessary information for an agent to use the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond schema descriptions, explaining multi-input consolidation, 'max' behavior, fee defaults, mutual exclusivity, and cap formula. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned Bitcoin native-send PSBT for segwit/taproot only, with a specific verb and resource. It distinguishes from siblings like prepare_btc_multisig_send and prepare_btc_lifi_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on fee selection, RBF, and high-fee overrides. Does not explicitly compare to siblings but covers many usage scenarios and constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior: uses marginfi_account_initialize_pda, PDA seeds, cost details (rent-exempt minimum + tx fee), rent refundability, durable nonce requirement, Ledger blind-sign, and error condition. Annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) are consistent with the description; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is packed with useful information but is somewhat lengthy. However, it is well-structured: purpose first, then details, cost, prerequisites, and error conditions. Every sentence adds value, so it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (Solana PDA initialization with Ledger and nonce), the description covers purpose, mechanics, cost, prerequisites, device compatibility, and error conditions. No output schema exists, but the description sufficiently informs the agent of all needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds meaning beyond the schema by explaining the deterministic PDA seeds, default accountIndex, and that wallet is both authority and fee_payer. This provides useful context beyond the basic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a transaction to create a deterministic MarginfiAccount PDA on MarginFi mainnet. It uses specific verbs ('build a tx that creates') and identifies the resource, and distinguishes from sibling tools by noting it is a one-time setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is a one-time setup required before supply/borrow/repay/withdraw, that it requires a durable nonce, and that it refuses if the account already exists. It also addresses Ledger compatibility and blind-sign requirements, providing clear when-to-use and prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, so mutation is expected. The description adds value by disclosing pre-flight refusal behavior, the condition for withdrawal (positive free collateral), and the blind-sign requirement on Ledger. No contradictions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences covering purpose, pre-flight behavior, prerequisites, and blind-sign. Every sentence adds value, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers all needed context: what the tool does, failure conditions, prerequisites, special parameter behavior (withdrawAll, blind-sign). Sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds meaningful context: 'withdrawAll' closes the position, 'amount' is human-readable and pre-flight checked, accountIndex allows segregation, symbol/mint resolution with auto-wrap for SOL. These details surpass schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds an unsigned MarginFi WITHDRAW transaction, specifying the action (withdraw from supplied position in a named bank) and differentiating from siblings like prepare_marginfi_supply or prepare_marginfi_borrow via explicit 'WITHDRAW' label and details about withdrawAll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (anytime a withdraw is needed) and when not to (pre-flight refusal if health factor too low, which would cause reversion). References prerequisites (durable nonce + init) and aligns with sibling tools like prepare_marginfi_supply, providing clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it's an unsigned transaction, immediate, involves a fee, requires durable nonce and blind-sign on Ledger. No contradiction with annotations; destructiveHint is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, packing essential information into a few sentences. It is front-loaded with the core action and efficiently conveys constraints and alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, constraints, and alternatives. It does not explain the return value format, but as a 'prepare' tool, the output (unsigned tx) is implied. The context is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by specifying that wallet must have an initialized durable-nonce account and mSOL position, and that amountMSol is human-readable with rounding down.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned immediate liquid-unstake transaction, burning mSOL for SOL via Marinade's liquidity pool. It explicitly distinguishes from delayed unstake, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: for immediate unstaking via liquidity pool, and contrasts with delayed unstake which is unsuitable for Ledger-only signing. It also notes required durable nonce and Ledger constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and idempotent, but the description adds details: it reverts on-chain if below liquidation threshold, no approval needed, and returns a handle+preview for Ledger signing. It explains why 'max' is not supported, which is behavioral context beyond annotations. No contradictions with annotations, but there is a contradiction with the schema's amount description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence stating the purpose, followed by important constraints and context. It is slightly verbose but still concise for the amount of information conveyed. Each sentence adds value, and the key points are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema), the description covers all critical aspects: purpose, constraints, prerequisites (query positions), on-chain behavior, and return format. It is sufficiently complete for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial semantic information by clarifying that 'max' is not supported, overriding the schema's misleading suggestion. It reinforces that amount should be exact human-readable decimals. This adds value beyond the schema's parameter descriptions, though it creates a contradiction with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned Morpho Blue withdrawCollateral transaction, specifying the action and resource. It distinguishes from siblings by focusing on collateral withdrawal and explicitly stating that 'max' is not supported, which contrasts with other withdraw tools. The verb 'build' and the target 'Morpho Blue withdrawCollateral' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises that 'max' is not supported and instructs to query get_morpho_positions first to know deposited collateral. It mentions that no approval step is needed, and implies that this tool is for withdrawing collateral, not borrowed assets (use prepare_morpho_withdraw). This provides clear when-to and when-not-to usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint, idempotentHint), the description adds crucial details: pre-flight check that refuses zero allowances, resolution of friendly spender labels, inclusion of previous allowance in description, and EVM-only constraint. This gives the agent a complete picture of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with each sentence adding unique value. It front-loads the core action, then covers pre-flight checks, label resolution, and TRC-20 distinction. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema), the description is quite complete. It explains the output (unsigned transaction) and workflow, but could be slightly more explicit about the return structure (e.g., that it returns a transaction object). However, it covers the key aspects for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides good descriptions for wallet, token, and spender. The description adds value by explaining the label resolution for spender and that the tool includes the previous allowance in the preview. This enhances semantic understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned approve(spender, 0) transaction to revoke an allowance. It specifies the resource (allowance on token for spender) and distinguishes from siblings by noting EVM-only and TRC-20 is handled by a different tool. The verb 'revoke' is specific and matches common user intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises pairing with get_token_allowances to list current approvals. It warns against using when the allowance is already 0, calling it a likely wrong pair. It also points to prepare_tron_trc20_revoke for TRC-20 tokens, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), description reveals it calls deposit() payable, mints rETH, preflights getMaximumDepositAmount(), and builds an unsigned transaction. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundancy. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a transaction builder, description explains the action and preflight behavior. Could be more explicit about the return value (unsigned tx data), but 'Build an unsigned transaction' sufficiently indicates output. No output schema, so description carries the burden well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: amountEth has a detailed description (human-readable ETH, example, min/capacity notes), wallet only has pattern. Description adds context for amountEth but not wallet. Compensates reasonably for the parameter description gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it builds an unsigned Rocket Pool stake transaction via deposit() payable to mint rETH. Specific verb+resource (prepare, stake) and distinguishes from siblings like prepare_rocketpool_unstake and other staking protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states Ethereum mainnet only and that rETH on L2s must be bridged, not deposit-and-mint. Also mentions preflight check for pool availability, guiding when the tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive hint and idempotent hint. Description adds that it does not serialize or fetch blockhash to preserve blockhash validity, handles auto nonce setup, bundles transactions, and dynamically adds priority fee. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but each sentence adds value. It is front-loaded with core purpose, then details prerequisites, amount details, priority fee, memo, nonce setup. Could be slightly more concise but earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: returns preview + handle, not final tx, nonce setup costs, memo program, Ledger clear-signing. Lacks details about exact preview format but is sufficient for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters (wallet, to, amount, memo) are well-described in the schema with patterns and examples. Description adds extra semantics: amount can be 'max', memo max 256 bytes, and explains behavior for each.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool builds an unsigned SOL native-transfer draft via SystemProgram.transfer, distinguishes from siblings like preview_solana_send and send_transaction, and specifies what it does not do (serialize or fetch blockhash).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (native SOL transfers), prerequisites (run pair_ledger_solana), and mentions the tool is part of a flow with preview_solana_send and send_transaction. It also provides alternatives and context for memo and nonce setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true. Description adds context: returns unsigned tx for later sending, cross-checks destination chain/receiver via decoding defense, handles NEAR Intents intermediate-chain, and error behavior on no route. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose but well-structured: purpose first, then scenarios, protocol routing, decoding defense, intermediate-chain handling. Front-loaded key info. Could trim internal references (e.g., issue #411, source-code constant) for conciseness, but organized for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 17 parameters, cross-chain complexity, non-EVM destinations, exact-in/out modes, protocol routing, and safety features, the description is exceptionally thorough. Covers edge cases like NEAR Intents, high-slippage flag, and decoding defense. No output schema, but return value explanation omitted per rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71% (12/17 parameters have descriptions). The tool description adds extra context beyond schema for toAddress, amount, amountSide, slippageBps, exchanges, bridges, excludeExchanges, excludeBridges, and order. It enriches parameter semantics significantly, so above baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prepares unsigned swap/bridge transactions via LiFi aggregator, distinguishing same-chain swaps and cross-chain bridges. It explicitly contrasts with siblings like prepare_solana_lifi_swap for Solana-source swaps and notes TRON-source isn't wired, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive when-to-use and when-not-to-use guidance: mentions alternative for Solana-source, explains exact-out mode, non-EVM destination requirements, protocol routing filters, high-slippage opt-in, and intermediate-chain bridge special case. No contradictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: on-chain position reading via positions(tokenId), hard refusal for non-owned tokenIds, automatic chaining of ERC-20 approvals, WETH-only limitation, slippage defaults and caps, and the ability to do single-sided deposits. Annotations already indicate readOnlyHint false, destructiveHint true, idempotentHint true, and the description adds significant context beyond these, such as the refusal mechanism and approval chaining. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured, starting with the main purpose, then explaining mechanics, warnings, limitations, and parameter details. Each sentence adds value, but it is slightly lengthy (6 sentences). It could be more concise by combining some points, but it remains clear and front-loaded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, annotations present), the description covers all critical aspects: purpose, when to use, preconditions, limitations, parameter behaviors, defaults, side effects (approvals), and related tools. The lack of output schema explanation is acceptable since the output is an unsigned transaction implied by 'build'. It addresses potential pitfalls (non-owned tokenId, WETH only) and provides enough context for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 78% of parameters with descriptions, providing a solid baseline. The description adds extra meaning: for tokenId, it recommends get_lp_positions; for amount0Desired/amount1Desired, it explains the '0' case for single-sided deposits; for slippageBps, it states default and combination with acknowledgeHighSlippage; for deadlineSec, it gives default; for approvalCap, it details options. This additional context compensates for the missing schema descriptions on wallet and chain (which are standard).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned Uniswap V3 increaseLiquidity transaction for an existing position. It specifies the verb 'Build', the resource 'unsign Uniswap V3 LP increaseLiquidity transaction', and explicitly distinguishes from siblings like prepare_uniswap_v3_mint by focusing on adding liquidity to an existing position. It mentions related tools (get_lp_positions) and sets clear context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: when to use (add liquidity to existing position), preconditions (tokenId must be owned by wallet, use get_lp_positions), limitations (only WETH, wrap native ETH via prepare_native_send), and parameter nuances (slippage defaults, soft cap requiring acknowledgeHighSlippage, single-sided deposit with amount0Desired: '0'). It effectively tells when not to use (non-owned tokenId) and directs to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations: it discloses that up to two ERC-20 approvals are chained automatically, USDT-style reset is handled, the pool must exist (else error), misaligned ticks are rejected rather than silently rounded, and v1 limitation of no native ETH. It also mentions slippage behavior and post-mint visibility in get_lp_positions. Annotations indicate destructiveHint=true and idempotentHint=true, which align with the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds value. The main purpose is front-loaded in the first sentence. Subsequent sentences cover approvals, constraints, v1 limitations, slippage, and post-mint behavior. There is no filler or redundancy; each clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and 14 parameters (8 required), the description is remarkably complete. It explains the transaction building process, pre-requisites (pool existence, tick alignment), parameter behavior, error cases, v1 limitations, slippage, and follow-up actions (NFT appears in get_lp_positions). It effectively equips an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 86% schema description coverage, the description adds significant meaning beyond the schema: it explains human-readable amounts vs raw wei, single-sided range deposits, tick alignment to tickSpacing, slippage defaults and soft caps, and approval cap options (unlimited/exact/specific). This provides essential context that the schema alone does not fully convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('build', 'opens') and resource ('unsigned Uniswap V3 LP mint transaction') to clearly define the tool's purpose. It distinguishes from sibling tools like prepare_uniswap_v3_burn by focusing on minting a new concentrated-liquidity position, and it explicitly states the pool and tick bounds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance for opening a new position, and when-not-to-use conditions: pool must exist, ticks must align to fee tier's tickSpacing, only WETH supported (not native ETH). It also mentions slippage defaults and the need for acknowledgeHighSlippage above 100 bps. However, it does not explicitly compare to sibling tools for existing positions (e.g., prepare_uniswap_v3_increase_liquidity), which would further clarify usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, destructive=false, idempotent, openWorld. The description adds critical behavioral traits: it follows proxies once, refuses non-view/pure functions, fetches ABI from Etherscan or requires inline ABI, validates types via viem. No contradictions; the description enriches transparency significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and well-structured, starting with a clear one-line summary. It covers many edge cases without being overly verbose. A slight reduction in examples could improve conciseness, but overall it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 2 required, no output schema), the description covers inputs, behavior, and restrictions thoroughly. It omits explicit return value format, but since the return is dynamic (function-dependent), this is acceptable. Provides sufficient context for an AI to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, but the description adds substantial meaning: explains ABI fetching options, function name disambiguation (full signature), argument type formatting with examples (decimal strings for uint256, hex for bytes32, addresses), and the `abi` parameter's override purpose. This goes well beyond the schema defaults and patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only tool for calling view/pure functions on EVM contracts, with explicit examples and a direct distinction from the write sibling `prepare_custom_call`. It covers the exact resource (contract state) and verb (read via function call), leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use (long tail of on-chain reads not covered by protocol-specific tools) and when not to (state-changing functions, unverified contracts without ABI). It provides alternative tool (`prepare_custom_call`) for writes, and offers detailed guidance on function disambiguation and argument formatting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description details behavioral traits: it marks the record as revoked at the current time, does not recall the token, and returns a specific structure. It does not contradict any annotations and adds valuable context about the limitation of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, each serving a purpose: stating the action, the caveat, the limitation, and the return/error conditions. It is front-loaded with the main action. While compact, it could be slightly restructured for clarity but is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the relatively simple tool with one parameter and no output schema, the description is comprehensive. It covers the action, important caveats, return format, error conditions, and differentiation from a more comprehensive recall mechanism. It provides enough context for an AI agent to use correctly without needing additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter (`name`) and 0% schema coverage, the description adds meaning by specifying it is the invite name and that the tool refuses if the name is unknown or already revoked. The schema provides pattern constraints, and the description adds context about the parameter's role and validation behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Revoke a previously-generated read-only share invite by `name`', using a specific verb and resource. It distinguishes itself from sibling tools like 'generate_readonly_link' by focusing on revocation and from 'list_readonly_invites' by being a mutation. The caveat about issuer-side bookkeeping further differentiates it from a hypothetical genuine recall tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool: only for issuer-side bookkeeping, not for actual token recall. It mentions the limitation that anyone holding the token can still query addresses, and that genuine recall requires Model B (hosted enforcement endpoint), deferred. It also states conditions for success and refusal (if name unknown or already revoked), providing clear guidance on when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: blocks until user signs/rejects, reads pinned nonce, requires prior preview_send for EVM, handles token expiry and single-use, and explains the retry risk acknowledgment. No contradiction with annotations (readOnlyHint false, destructiveHint true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence and logical flow by chain. However, it is verbose (multiple paragraphs) and could be slightly more concise without losing critical context for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema), the description covers usage, prerequisites, parameter behavior, error conditions, and security considerations. However, it does not describe the return value (e.g., transaction hash), leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, including the rationale for parameters like previewToken (to prevent skipping preview), userDecision (user affirmation), and acknowledgeRetryRiskAfterAmbiguousFailure (duplicate prompt risk). It explains chain-specific parameter handling (e.g., TRON ignores previewToken).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forwards a prepared transaction to a Ledger device for user signing, differentiating between EVM and TRON handling. It specifies the verb (send) and resource (transaction via handle), and distinguishes itself from sibling prepare_* and preview_send tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: after a prepare_* call, with EVM requiring a prior preview_send and TRON requiring pair_ledger_tron. It details required parameters (confirmed: true, previewToken, userDecision) and conditions for acknowledgeRetryRiskAfterAmbiguousFailure. It also warns against using raw calldata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses comprehensive behavioral traits beyond annotations: it walks top-level method/events, decodes events, shows balance changes, fee, and heuristics. It also notes limitations (v1 coverage, top-level only, current spot pricing) and confirms read-only, no signing/broadcast. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with valuable information and well-structured (purpose, agent behavior, details, distinctions, use cases, limitations). However, it is somewhat verbose, but every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description thoroughly explains what the tool returns (structured envelope and pre-rendered narrative). It covers supported chains, limitations, pricing, and parameter behavior, making it complete for an agent to understand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters are fully described in the schema (100% coverage). The description adds context for wallet (defaults to sender, computes perspective) and format (both structured and narrative returns), going beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides 'narrative analysis of a single confirmed transaction', listing specific decoded elements and use cases. It distinguishes itself from siblings like get_transaction_status and the prepare→preview→send pipeline, ensuring no overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to call this tool (when a user pastes a tx hash and asks why it failed/what it does) and what NOT to do (do not WebFetch explorer pages because they are JS SPAs). It also distinguishes from related tools, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds details beyond annotations: it explains that the tool can broadcast (destructive behavior), returns broadcastedTxid on success, and refuses with per-input breakdown when threshold not met. It also aligns with annotations (destructiveHint=true, idempotentHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loaded with the main action, and each sentence provides essential information without redundancy. It efficiently covers purpose, usage, behavior, and options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully explains return values (tx hex, optional broadcastedTxid) and error conditions (refusal per input). For a complex tool, it covers all needed aspects for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context: psbtBase64 must be fully signed, broadcast parameter effect is explained. While the schema already describes parameters, the description clarifies the prerequisites and outcomes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Finalize' and the resource 'fully-signed multi-sig PSBT', and explicitly distinguishes from sibling tools like 'combine_btc_psbts' by referencing it as the typical preceding step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use (after combine_btc_psbts when threshold is met) and when broadcast=true vs false, and describes the refusal behavior for incomplete signatures. It also notes 'No device touch', contrasting with signing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds behavioral details: snapshots most recent fetchGroupData pass, warms cache on demand, describes output fields including recovery from raw bytes. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but slightly verbose (e.g., details about SDK version and IDL version). However, it is well-structured with purpose, return details, usage guidance, and cache behavior. Every sentence adds value, so it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (diagnostic for a specific client), empty schema, and no output schema, the description fully explains purpose, usage context, output details, and behavioral traits. It is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description explicitly confirms 'No input args.' The description cannot add more meaning because there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a diagnostic surface for the hardened MarginFi client load, returning a list of skipped banks with detailed fields. It distinguishes itself from sibling tools like prepare_marginfi_* and get_marginfi_positions by focusing on diagnostics rather than operations or position queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: call when prepare_marginfi_* reports a mint is missed. Explains tool behavior—either names the skipped bank with cause or confirms mint not in group. No mention of when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, openWorldHint) indicate safe, read-only operation. Description adds concrete behavioral details: returns flagged bit, incident flag, utilization thresholds, and per-protocol logic, beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded with purpose, but somewhat dense with repeated protocol details. Could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description fully explains return fields (flagged bit, incident flag, per-reserve flags, utilization, supply, borrow). Covers all protocols and edge cases adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. Description adds value by explaining how each enum value affects return logic (e.g., bitcoin computes hash_cliff, empty_block_streak) and wallet usage for specific protocols.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns an 'is anything on fire' snapshot across markets, with per-protocol details (Compound, Aave, base-layer chains). It distinguishes itself from sibling get_compound_market_info by collapsing multiple calls into one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use when suspecting governance pause, utilization cliff, or multi-market contagion. Contrasts with get_compound_market_info for alternative when detailed per-market info is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description complements annotations (readOnlyHint, destructiveHint, idempotentHint) by adding that it's a 'read-only display tool', explains the small page cap as a fabrication-resistance guard, and details the output fields. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and front-loaded with core purpose, then differentiates from siblings, describes source/fields, and ends with agent behavior. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description details the return fields (tokenId, priceEth, etc.) and constraints (EVM-only, single-token criteria, small page cap). Completely covers what an agent needs to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 3 parameters. Description adds value by explaining the purpose of the 'limit' cap (fabrication-resistance) and reinforcing the contract requirement. Slightly above baseline due to added context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it returns 'Ranked individual listings (currently active asks) for a single EVM NFT collection on a single chain, sorted floor-ascending.' It also distinguishes from sibling `get_nft_collection` by noting the latter only provides collection-level metadata, making the purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit when-to-use guidance (research/candidate selection) and when-not-to (execute buy via marketplace UI until prepare flow lands). Also notes EVM-only and Solana deferred, providing clear context on limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world. The description adds rich behavior context: fan-out across chains, address folding for non-EVM ecosystems, response structure with totalUsd and breakdown, error degradation via coverage, and mention of follow-up phases (Solana staking). 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long due to complexity but is efficiently structured: core purpose in first sentence, then ecosystem-specific details, then usage guidance. Every sentence provides unique value, no redundancy. Properly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description adequately describes return fields: totalUsd, breakdown by category/chain, raw per-protocol arrays, specific fields like tronUsd, tronStakingUsd, coverage. Also handles edge cases (multi-wallet, single wallet, error degradation). Complete given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 11 parameters with detailed descriptions. The tool description adds value by explaining interdependencies (mutual exclusions between single/multi address params, behavior with single wallet vs wallets array, constraints like max items for tronAddresses (10) and solanaAddresses (5)). Slightly richer than baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does 'one-shot cross-chain portfolio aggregation' and lists the specific protocols and assets included. It distinguishes itself from sibling tools by being the default for portfolio value questions, contrasting with per-protocol readers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Default tool for 'what's in my portfolio?' / 'total value' questions; prefer it over calling each per-protocol reader separately.' This provides clear when-to-use guidance and warns against unnecessary multiple calls, fitting the usage guidelines dimension perfectly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds critical context: the tool surfaces data, does not endorse or pick tokens, and clarifies what a high score means (contract safety, not investment upside). 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-structured with clear sections (SCOPE, AGENT BEHAVIOR). Every sentence adds value, though some repetition could be trimmed. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and the description fully explains the return value (0-100 score, higher safer), the factors considered, and the intended use cases. Covers all necessary context for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero description coverage for the only parameter 'protocol'. The description fully compensates: explains it's a DefiLlama slug, works across chains, and provides concrete examples (Solana, Tron, EVM). Makes the parameter unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 0-100 risk score for a DeFi protocol based on multiple factors (TVL, trend, age, audits, bug bounty). It specifies the protocol argument as a DefiLlama slug and gives examples across chains, distinguishing it from any sibling tool like check_contract_security or get_coin_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use for protocol due-diligence (e.g., comparing Aave V3 vs Compound V3), and explicitly warns against using for speculative token picks. Provides clear 'do NOT use' scenarios and explains what the score does and does not indicate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and safe. The description adds details on the Jupiter API call, return structure (opaque quoteResponse plus human fields), auto-wrapping/unwrapping for SOL, and error behavior when no route exists, going well beyond 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs, front-loaded with 'READ-ONLY' and core purpose. Every sentence adds value—no fluff. Well-organized, easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema), the description covers all essential aspects: what it returns, how to use parameters, error behavior, and relationship to sibling tools. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline is 3. The description adds value with concrete examples (e.g., '1000000' for 1 USDC), explains the native SOL mint convention, and gives common DEX names and usage patterns for the dexes parameter. This additional context justifies a 4 rather than a 5 because the schema already does much of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches a Jupiter v6 swap quote for previewing route, expected output, slippage, and price impact. Distinguishes from sibling tools like 'get_swap_quote' (EVM) and 'prepare_solana_swap' by naming the aggregator and usage purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'READ-ONLY' and to use before committing to a transaction. Mentions the quoteResponse must be passed verbatim to 'prepare_solana_swap', provides guidance on native SOL mint handling, DEX filtering, and error recovery ('agent should offer to retry without filter').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds context that no transaction is built, quotes are returned, cross-chain settlement takes 1-15 minutes, and exact-out is not supported for certain chains. It also explains the protocol routing selection behavior and the need to surface routedVia.tool. No contradictions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose but well-structured with multiple paragraphs covering different aspects. Every sentence adds value, but it could be slightly more concise. However, given the complexity of the tool, the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all major aspects: purpose, usage guidelines, parameter details, behavioral nuances, output expectations (expected output, fees, execution time, tool selected), and cross-chain specifics. It even includes a note about protocol routing issue #411 and how to handle user requests for specific DEXes. No output schema exists, so the description sufficiently explains the return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (71%), but the description adds significant meaning beyond the schema: it explains exact-in/exact-out semantics, the behavior of exchanges and bridges parameters, the order parameter, and the required toAddress for cross-chain to Solana/TRON. It also clarifies that amount is human-readable, not raw units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a LiFi aggregator quote for token swaps or bridges, specifying it is for quotes only and not transaction building. It distinguishes from sibling tools like prepare_solana_lifi_swap by noting that tool is for Solana-source swaps, and from prepare_swap which builds transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance: exact-in vs exact-out, cross-chain behavior with destination chain details, protocol routing via exchanges/bridges, and when to use the tool vs alternatives. It explicitly states that for Solana-source swaps, use prepare_solana_lifi_swap, and for TRON-source, it's not yet wired.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the entire process: pulling Approval events, deduplication, live re-read via Multicall3, dropping zero allowances, and sorting. It also states read-only nature, no signing/broadcast, and EVM-only restrictions. This goes well beyond the annotations (readOnlyHint, destructiveHint, idempotentHint) and adds rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite detailed but every sentence adds value. It is front-loaded with the core purpose and logically flows through process, usage, and scope. A slight reduction from 5 due to length; however, it remains well-organized and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description fully explains the return structure (fields like spenderLabel, currentAllowanceFormatted, unlimitedCount, notes). It also covers edge cases (unlimited detection) and limitations (TRON, Solana). For a moderately complex tool with 3 parameters, this is exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical nuance: for 'wallet' it specifies the role as indexed owner, for 'token' it excludes wrappers and native coins, and for 'chain' it notes default and per-chain differences. Additionally, it describes the response fields (spender, allowance details, provenance), which are not in the input schema, greatly enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates spenders with non-zero allowance for a specific token on a single EVM chain. It uses specific verbs ('Enumerate', 'Pulls', 're-reads') and explicitly contrasts with sibling tools by mentioning Solana and TRON scope limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('security audits, pre-tx checks, revoke-cleanup workflows') and when not to (native coins not supported, Solana out of scope). It also provides context on per-chain differences, guiding the agent to make one call per chain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) are known; the description adds behavioral details: sequence remains at 0xFFFFFFFD for further RBF, returns a 15-min handle for send_transaction, and lists all refusal conditions. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with all necessary information. It could benefit from structuring refusal cases as a list, but it remains clear and front-loaded with the main purpose. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (BIP-125 RBF) and absence of an output schema, the description covers all aspects: mechanism, integration with send_transaction, refusal cases, and safety constraints. It is thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have descriptions in the schema; the description adds context: wallet scope (native segwit/taproot), txid eligibility (sequence condition), newFeeRate dust threshold and rule 4, allowHighFee cap formula. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a BIP-125 RBF replacement for a stuck mempool BTC transaction, specifying reuse of inputs, preservation of recipients, and shrinking change output. It distinguishes from siblings like prepare_btc_send by outlining the unique RBF mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (stuck mempool tx) and lists refusal cases (already confirmed, no BIP-125-eligible input, multi-source out-of-scope, no change output, rule 4 violation, dust threshold, fee cap). It implies alternatives like CPFP when no change output. Provides clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=true), the description details behavioral traits: bypasses canonical-dispatch allowlist, fetches ABI via Etherscan if not provided, follows proxies once, validates args with viem, and explains the verification envelope. No contradictions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but becomes lengthy with detailed paragraphs. While comprehensive, it could benefit from bullet points for readability. Nonetheless, every sentence adds value, and it is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema, annotations present), the description covers all essentials: usage context, safety acknowledgments, parameter semantics, ABI handling, and verification. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 91% (high), but the description adds significant meaning: it explains the escape hatch nature, proxy behavior, ABI sourcing options, and the role of each acknowledge flag as a safety gate. It also clarifies raw wei format and argument type constraints beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an escape hatch for arbitrary EVM contract calls not covered by protocol-specific prepare_* tools. It specifies the verb (prepare) and resource (custom call), and distinguishes from siblings by advising to use a protocol-specific prepare_* when one fits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (long tail, governance hooks, DAO ops) and when not to (if a protocol-specific prepare_* exists). It provides guidance on ABI sourcing, proxy handling, function signatures, and the mandatory acknowledgeNonProtocolTarget flag, ensuring the agent understands the trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the internal transaction composition (computeBudget, ATA setup, reserve refresh, etc.), decimal resolution, and validation against Kamino's main market. Adds significant detail beyond annotations (destructive, idempotent) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) but packs essential information: purpose, prerequisites, human amounts, nonce requirement, and tx composition. Front-loaded with the core action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a Kamino supply transaction and no output schema, the description is complete: it explains the prerequisite, input validation, parameter interpretation, and what the returned transaction contains, enabling correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters, including human amount semantics. The description adds context about market validation and prerequisite (wallet initialization) for the wallet param, complementing the schema effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Build a Kamino deposit (supply) tx' with specific verb and resource. It distinguishes from siblings like prepare_kamino_init_user and prepare_kamino_borrow by mentioning prerequisites and the deposit-specific flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (after prepare_kamino_init_user) and what not to use (if not initialized). Also mentions required nonce and Ledger blind-sign treatment, guiding the agent on prerequisites and signing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses preflight behavior (rETH balance and collateral check), conditional failure with alternative hint, and mentions building an unsigned transaction. This adds context beyond annotations (destructiveHint, idempotentHint) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with core purpose, and each sentence provides essential information (operation, no approval, preflight, alternative). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently covers input parameters, behavior, and failure conditions. It integrates an alternative tool, making it self-contained for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers one parameter (amountReth) with detailed description and example; the tool description reinforces it. The wallet parameter lacks schema description but is a standard address field, and the description doesn't add further. Coverage is 50%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool builds an unsigned Rocket Pool unstake transaction via rETH.burn, redeeming rETH for ETH from on-protocol collateral. It distinguishes from siblings like prepare_uniswap_swap by specifying no approval needed and preflight conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: preflights balance and collateral, refuses if collateral insufficient, and directs to use prepare_uniswap_swap as an alternative. It also notes no approval is needed, clarifying when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive (mutation) and idempotent hints. The description adds extensive behavioral context: uses v0 VersionedTransaction with Address Lookup Tables, requires durable nonce, returns an opaque handle, and mentions blind-sign requirements on Ledger. It also notes error behavior if nonce uninitialized, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, starting with the core purpose, then prerequisites, technical details, and usage flow. Every sentence adds necessary information without redundancy, and the structure is front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains return values (compact preview + opaque handle) and the required follow-up steps (preview_solana_send then send_transaction). It covers Ledger blind-sign requirements and CHECKS block references, making it complete for an AI agent to understand the tool's lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The tool description reinforces the meaning of 'quote' (must be verbatim from get_solana_swap_quote) and prioritizationFeeLamports (optional, recommend omit). It adds value by explaining Jupiter's signature requirement, but baseline is already high due to schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Build an unsigned Jupiter-routed swap DRAFT' with a specific verb ('build') and resource ('unsigned swap draft'). It distinguishes itself from sibling tools like prepare_solana_lifi_swap (different router) and prepare_solana_native_send (different operation) by specifying Jupiter routing and the draft nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when to use: after obtaining a quote from get_solana_swap_quote. It also states prerequisites (durable nonce initialized via prepare_solana_nonce_init) and the subsequent steps (call preview_solana_send then send_transaction). It explicitly notes that the output is not yet signable, providing a complete usage flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true, but description adds extensive behavioral context: steps, verification, refusal conditions, blind-signing requirement. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but every sentence adds value. Well-structured with clear steps and details. Could be slightly more concise, but still highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity and absence of output schema, description covers input, process, error handling, and prerequisites comprehensively. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning beyond schema: explains each parameter's role, edge cases (non-canonical decimals), and refusal reasons (e.g., insufficient allowance).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it builds an unsigned SunSwap V2 same-chain swap on TRON, specifies router address, selectors, and path encoding. Distinguishes from sibling tools like prepare_swap and other swap-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (SunSwap V2 only, not Smart Router) and prerequisites (approve TRC-20, pair Ledger, enable blind signing). Provides detailed process and error recovery hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint, idempotentHint), description details the 14-day cooldown, output format (preview + opaque handle), hardware signing requirement via Ledger, and the relationship between unfreeze and withdraw steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each serving a clear purpose: action, constraint, post-action, output, forwarding. No fluff, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains the return value (preview + opaque handle) and how to use it. Covers the full lifecycle from frozen to unfrozen to withdraw, making it complete for a transaction-building tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds practical constraints: amount must not exceed frozen balance (links to get_tron_staking), and explains resource enum values (bandwidth for plain txs, energy for smart contracts), which adds value beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned UnfreezeBalanceV2 transaction, begins a 14-day cooldown, and differentiates from sibling tools like prepare_tron_withdraw_expire_unfreeze by specifying the lifecycle step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to query get_tron_staking first to verify frozen balance, warns of rejection otherwise, and directs to call prepare_tron_withdraw_expire_unfreeze after 14 days. Also mentions forwarding via send_transaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by describing auto-picking fee tier via QuoterV2, returning an unsigned tx with optional reset+approve chain, and detailing support for native tokens and exact-in/exact-out. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with purpose and usage guidance. Every sentence adds value without repetition. Length is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers swap types, fee selection, slippage, approval handling, and fallback behavior. No output schema, but describes return as unsigned tx for send_transaction. Complete given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to parameters like `amount` (human-readable), `feeTier` (optional override), `slippageBps` (default 50, cap 500), and `acknowledgeHighSlippage`. Schema coverage is 64%, but description compensates well for missing schema descriptions on other params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Prepare a direct Uniswap V3 swap (bypasses LiFi aggregator)', specifying the exact protocol and distinguishing it from the sibling `prepare_swap`. It also details supported swap types (same-chain, native in/out, exact-in/exact-out).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use only when user asks for Uniswap, otherwise default to `prepare_swap`. Also notes that multi-hop routes fall back to `prepare_swap`. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals key behaviors beyond annotations: canonical-registry-only, no on-chain probing, bridged variant warnings, and error handling with suggestions. Annotations indicate readOnly and idempotent, which description reinforces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise while covering main purpose, edge cases, and usage guidance. Front-loaded with core function, then details, then actionable advice. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (multi-chain, bridged tokens, no output schema), description fully prepares the agent: what to expect, how to handle ambiguity, unknown tokens, and integration with sibling tool. Complete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value with examples, case-insensitivity note, and explanation of registry-only resolution. This supplements schema meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Resolve a (chain, symbol) pair to its canonical contract address + decimals from the curated registry.' It specifies supported chains and highlights ambiguity handling, distinguishing it from tools like `prepare_token_send`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'USE THIS BEFORE `prepare_token_send` when the user names a token by symbol' and provides guidance for unknown symbols, including alternatives like calling `prepare_token_send` with explicit address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds context: runtime-only memory, takes precedence over env var, rejects URLs to prevent prompt injection, and clarifies persistence. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and well-organized, though somewhat lengthy. Every sentence adds value, but slight trimming could improve conciseness. Still very good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the effect (used for subsequent Solana calls until restart), security considerations, persistence, and agent behavior. Complete for a simple setter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'apiKey' is fully described in both schema (coverage 100%) and in the description, which adds detail about UUID format, bare key requirement, and where to obtain it. The description enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a Helius API key for Solana RPC reads at runtime without restart, constructs the canonical URL, and explains its precedence. This is a specific verb+resource that distinguishes it from sibling tools like set_demo_wallet or set_etherscan_api_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'when the user pastes a key in chat...call this tool immediately.' It also tells where to get the key (Helius dashboard), what not to do (never echo the key), and offers an alternative for persistence across restarts (vaultpilot-mcp-setup).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true. The description adds rich behavioral details: decodes PSBT, validates bip32_derivation as a security check, forwards to Ledger for output walkthrough, splices signatures, and returns partial PSBT. It explains the size limit and that signing is irreversible. No contradiction with annotations; it significantly supplements them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but efficiently packs all necessary information. It front-loads the core purpose ('Co-signer flow') and then logically flows through steps, constraints, and security notes. Every sentence adds value without redundancy. For the complexity of the tool, it is remarkably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-sig signing with Ledger, security checks), the description is complete. It references the prerequisite registration tool, explains the workflow, user verification step, return value (partial PSBT), and limitations (no finalization). It covers all essential aspects without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with both parameters well-documented. The description adds extra context beyond the schema, such as the validation step (bip32_derivation check) and the requirement that the wallet must be registered. While the schema already provides the basics, the description enhances understanding with workflow details, justifying a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for co-signing a multi-sig PSBT by adding our Ledger signature. It specifies the initiators (Sparrow, Specter, etc.) and distinguishes from siblings like finalize_btc_psbt by explicitly noting we do not finalize or broadcast. The verb 'sign' and resource 'BTC multisig PSBT' are exact, and it differentiates from other signing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use: when an external initiator produces a PSBT needing our signature. It also tells when not to use: we don't finalize or broadcast, and it only works for wallets registered via register_btc_multisig_wallet. The description includes prerequisites (registered wallet, PSBT with bip32_derivation) and user responsibilities (verify outputs on-device). Clear context with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant detail beyond annotations: no signing/broadcasting, return format includes {ok, returnData?, revertReason?}, and explains state-dependent behavior (msg.sender) and need for approval confirmation. Annotations already declare readOnlyHint, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence serves a purpose: definition, return, use case, examples, and warnings. No redundancy, well-structured with logical flow from what to when and how not to use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the return format. Covers prerequisites (approval confirmation), state-dependency, and usage context. Comprehensive for a simulation tool with behavioral nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% (from, data, value have descriptions; chain and to lack). The description compensates by explaining the purpose of 'from' for state-dependent calls and 'data'/'value' formats, but does not add detail for 'chain' or 'to' beyond schema. Overall adds value but not perfectly comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates an eth_call without signing/broadcasting, returns a structured object, and distinguishes from prepare_*/send_transaction tools. Examples like WETH wrapping and custom calldata reinforce the specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance to use before prepare_*/send_transaction to verify contract calls. Specifically warns against calling after an unconfirmed approval, providing a clear 'when not to use' scenario. Implicitly contrasts with send_transaction for actual execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly and idempotent; description reinforces READ-ONLY, explains that it never refuses signing but surfaces verdict, and describes execution time. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with key info front-loaded, but slightly verbose. Still, every sentence adds value, so it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains all possible return values, platform-specific behavior, limitations, and prerequisites. An agent can confidently select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter's schema description already provides basics, but the tool-level description adds critical context: defaults, requirement on Linux, and unsupported installs. This significantly aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs codesign verification of the Ledger Live binary across three platforms, with per-platform tooling and return values. It distinguishes from sibling verification tools by specifying binary codesign specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to run (after install/update/OS update), warns about Linux path requirement and unsupported installs, and advises not to auto-fire due to latency. Provides alternatives for unsupported package managers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it fetches from 4byte.directory, re-decodes via viem, re-encodes, and is more expensive than a simple selector lookup. Describes the summary field as pre-written for end-user consumption. No contradiction with annotations (readOnlyHint true, etc.). Adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence provides necessary context. It is well-structured, starting with core purpose and then details. Slightly verbose but justified by complexity; could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in transaction verification, the description covers all essential aspects: input, process, output (VerifyDecodeResult with summary), special case TRON, status meanings, and warnings. No output schema but enough detail for an agent to use correctly. Annotations support its safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'handle' is explained in detail: it is the opaque ID from prepare_* tools, to be used when context is lost; the server re-emits the same data; warns against reading from disk. This adds significant meaning beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs an independent server-side cross-check of an EVM transaction's calldata. It specifies the verb (verify, cross-check) and resource (EVM tx calldata), and distinguishes itself from ad-hoc alternatives ('NEVER do this check by scripting ad-hoc WebFetches...').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after preparing a transaction) and when not to use (on TRON returns not-applicable). Provides clear action based on status: mismatch means 'DO NOT SEND', and fallback recommendations for other statuses. Also names an alternative (swiss-knife URL) and warns against it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it is composed from existing tools (not new on-chain reads), returns both structured and narrative formats, handles sub-tool failures gracefully, and explicitly lists missing features. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence provides necessary information. It front-loads the core purpose and efficiently covers sections, parameters, and limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's complexity, the description fully explains the return format (structured envelope and narrative), sections, failure mode, and punted features. It is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by explaining address args mirror get_portfolio_diff, period defaults, and format options for agents. It enriches the meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a one-paragraph portfolio briefing composed from existing tools. It distinguishes itself from sibling tools get_portfolio_summary and get_portfolio_diff by specifying it is a conversational rollup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use this tool: for a quick 'what's going on' briefing, defaulting to 24h. It also notes what is not covered (two punted sections with available: false) and differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the session persists for future transactions, adding context beyond annotations (idempotentHint, destructiveHint). No contradictions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose. No unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pairing tool with no parameters and no output schema, the description covers purpose, output, usage constraints, and persistence behavior. Fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the description compensates by explaining the output (URI + QR code) and the purpose. No parameter documentation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (initiate a WalletConnect v2 pairing session), the target (Ledger Live), and the output (URI and ASCII QR code). Distinct from sibling tools like 'pair_ledger_tron'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies 'EVM chains only' and directs to a sibling tool for TRON ('use pair_ledger_tron instead'). Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses bundling of ERC-20 approvals, slippage computation via server, and rejection of meta pools. Consistent with annotations; no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is informative and purposeful, front-loaded with primary action, then sequentially covers details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all critical aspects: purpose, parameter usage, scope constraints, prerequisites, and behavioral nuances. Adequate given no output schema and 6 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds substantial detail beyond schema: amounts format as decimal strings with '0' for empty slots, slippage gate requirement with two forms, approvalCap behavior (unlimited/exact/custom min), and the prerequisite get_curve_positions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds an unsigned Curve add_liquidity transaction for stable_ng plain pools, with specific verb and resource, and distinguishes from sibling tools like prepare_curve_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states scope limitations (only stable_ng plain pools, meta pools rejected), requires slippage gate with two options, recommends using get_curve_positions for discovery, and explains approvalCap options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses automatic approval chaining for ERC-20, coin index resolution from pool's coins array, and the security gate acknowledgeNonAllowlistedSpender because Curve pool is not in the global allowlist. Annotations already mark destructive and idempotent; description adds rich behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value. Front-loaded with purpose, then specifics on pools, parameters, slippage, approvals, exclusions, and fallback. Efficient and clear despite length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all relevant aspects: supported pools, coin index logic, slippage safety, approval gates, fallback, and allowlist rationale. For a complex 10-parameter tool with no output schema, it is remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description significantly enriches parameters: explains slippageBps calculation, minOut precedence, the reason for acknowledgeNonAllowlistedSpender, and approvalCap options. Exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Build an unsigned Curve swap on Ethereum' and specifies supported pools (canonical stETH/ETH and stable_ng factory plain pools). It also distinguishes from sibling tools like prepare_swap by noting fallback for unsupported Curve pairs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: for supported Curve pools; when-not-to-use: for meta pools, cryptoswap, tricrypto, older legacy pools; and alternatives: fall back to prepare_swap (LiFi). Also details required slippage gate with rationale about MEV.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and idempotent. Description adds technical details: uses v0 VersionedTransaction, MarginFi group ALTs for compact wire size, and blind-sign on Ledger. No contradiction with annotations. This goes beyond annotations to warn about ledger signing and transaction type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph that efficiently covers purpose, prerequisites, technical details, and parameter hints. Every sentence is informative without redundancy. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, no output schema), the description covers all necessary aspects: prerequisites, usage conditions, technical behavior, parameter semantics, and ledger interaction. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions (100% coverage). Description adds context: wallet must have initialized MarginfiAccount and nonce; symbol lists canonical tokens and explains SOL/wSOL handling; mint explains override; accountIndex explains position segregation; amount clarifies human-readable format and decimal resolution. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned MarginFi SUPPLY transaction for a given bank, specifying the action, resource, and outcome. It distinguishes from sibling tools like prepare_marginfi_borrow and prepare_marginfi_withdraw by focusing on supply and mentioning earning supply APY.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites: durable nonce required and prepare_marginfi_init must run first. Provides pre-flight checks and guidance on when to use symbol vs mint. Includes blind-signing instructions, which helps the agent avoid errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses crucial behavioral details: refusal to default decimals due to safety risks with Ledger blind-sign, unsupported unbounded approvals, and return format (preview + opaque handle). 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading purpose, and every sentence provides essential information. Length is appropriate given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers the tool's purpose, usage context, parameter details, return value, and important warnings. Sufficient for an agent to invoke correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant meaning for each parameter, including the primary spender use, canonical token set for decimals, human-readable amount format, and fee limit default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned TRC-20 approve transaction, specifying the verb and resource with precise scope. It distinguishes from sibling tools by mentioning its primary use with LiFi and linking to prepare_tron_lifi_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (authorize LiFi before swap) and when not to use (no 'max' approvals, must provide decimals for non-canonical tokens). Provides clear context and constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, openWorldHint. Description adds behavior: server-side pinning, hash computation, block return, handle expiration (15 min), re-call behavior (with/without refresh), deterministic forwarding to send_transaction. Rich context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each adding critical info: purpose, why surface now, stashing mechanism, refresh behavior, exclusions and error. No fluff, front-loaded with key constraint 'EVM-only'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema but 2 parameters, description thoroughly covers all behavioral aspects, lifecycle, error conditions, and alternatives. No missing information for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters (handle, refresh) with descriptions, but description adds significant meaning: handle's lifecycle (from prepare_*, link to send_transaction, expiration, refresh behavior), refresh semantics (re-pin vs return existing). No gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'EVM-only: finalize an already-prepared transaction for signing by pinning the nonce, EIP-1559 fees... and computing the EIP-1559 pre-sign RLP hash'. It uses specific verbs and resources, and distinguishes from siblings like preview_solana_send and send_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: before send_transaction, and why (Ledger blocks tool call). Provides exclusions: not for TRON or Solana, and directs to preview_solana_send for Solana. Covers edge cases like re-calling to refresh and error if no prior call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that by default no data is transmitted (only a pre-filled URL), explains alternative posting behavior, rate limiting, and dedupe. Annotations (readOnlyHint=false, destructiveHint=false, etc.) are consistent and description adds critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive: purpose, usage guideline, behavior modes, rate limits, and writing advice in a few sentences. Front-loaded with purpose and critical usage constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (2 required), nested context object, and no output schema, the description fully covers behavior, response modes, rate limits, and dedupe. Schema descriptions handle parameter details, so description completes the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, and the description enriches parameter semantics by advising on how to write summaries and descriptions (e.g., 'One-line title...', 'What the user asked for...'). This goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it files a capability request for missing functionality, with specific examples (unsupported protocol, chain, token, missing tool). It distinguishes itself from siblings by being the fallback when no tool exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'USE ONLY AFTER confirming no existing tool can accomplish the task.' Provides when-to-use, alternative approach, and details on behavior (GitHub URL vs direct post, rate limits, dedupe).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/agenthill/vaultpilot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server