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

With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose that this likely involves a blockchain transaction (implied by mnemonic parameter), potential costs (gas), irreversible effects, or response format. For a tool with 8 parameters including sensitive mnemonic, this is inadequate.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.

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

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

For a complex IBC transaction tool with 8 parameters, sensitive mnemonic input, no annotations, and no output schema, the description is insufficient. It doesn't explain what acknowledgment means in IBC context, transaction implications, or expected outcomes. The gap between complexity and description depth is significant.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional parameter information beyond the tool's purpose. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description 'Acknowledge receipt of an IBC packet' clearly states the action (acknowledge) and resource (IBC packet). It's specific enough to understand the core function, though it doesn't explicitly differentiate from sibling tools like 'timeout-packet' which handles packet timeouts rather than acknowledgments.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, timing considerations, or related tools like 'timeout-packet' for handling unacknowledged packets. Usage context is implied but not stated.

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

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. 'Begin unlocking' suggests a multi-step process or initiation, but it doesn't disclose whether this is a transaction that requires signing (implied by mnemonic parameter), has network fees, affects token availability, or what 'begin' means operationally. No rate limits, idempotency, or error conditions are mentioned.

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, avoiding unnecessary elaboration while stating the core purpose directly.

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

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

For a tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'begin unlocking' entails (e.g., transaction initiation, unlock period start), expected outcomes, error handling, or how it fits into broader unlocking workflows. The lack of behavioral context and output information leaves significant gaps for agent understanding.

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

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

Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional meaning beyond implying 'specific locked tokens' relates to the 'id' and 'coins' parameters, but doesn't clarify parameter interactions or usage nuances. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description 'Begin unlocking specific locked tokens' clearly states the action (begin unlocking) and target (locked tokens), but it's vague about what 'begin' entails versus completing the unlock process. It distinguishes from 'begin-unlocking-all' by specifying 'specific' tokens, but doesn't clarify how it differs from 'unlock-period-lock' or other unlocking-related siblings.

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

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

No guidance is provided on when to use this tool versus alternatives like 'begin-unlocking-all' or 'unlock-period-lock'. The description implies it's for specific tokens, but doesn't explain prerequisites (e.g., requires locked tokens), exclusions, or contextual triggers for choosing this over other unlocking tools.

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

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

With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this is a transaction requiring blockchain confirmation, gas costs implications, irreversible effects, or what 'begin' implies (e.g., initiation vs. completion). Critical for a write operation.

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

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

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

For a write operation with no annotations and no output schema, the description is insufficient. It lacks details on behavior, outcomes, errors, or side effects. Given the complexity (transaction signing with mnemonic) and missing structured data, more context is needed for safe use.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying the action applies to an account (though 'account' isn't a parameter). Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the action ('Begin unlocking') and target resource ('all locked tokens for an account'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'begin-unlocking' (singular) or 'unlock-period-lock', leaving some ambiguity about scope.

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

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

No guidance is provided on when to use this tool versus alternatives like 'begin-unlocking' (for individual tokens) or 'unlock-period-lock'. The description implies a bulk operation but doesn't clarify prerequisites, timing, or constraints, offering minimal usage context.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Cancel' implies a destructive write operation, but the description doesn't mention permission requirements, transaction finality, side effects, or error conditions. This is inadequate for a tool that likely involves governance or administrative actions.

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

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

The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately comprehensible without unnecessary elaboration.

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

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

For a tool with no annotations and no output schema, the description is insufficiently complete. It lacks critical behavioral details (e.g., transaction requirements, success/failure outcomes) and doesn't compensate for the absence of structured metadata, leaving significant gaps in understanding how to use the tool effectively.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional parameter context beyond implying the tool acts on 'pending software upgrades,' which doesn't clarify parameter usage or relationships. This meets the baseline for high schema coverage.

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

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

The description clearly states the verb ('Cancel') and resource ('a pending software upgrade'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'upgrade-proposal' or other governance-related tools, which would require explicit differentiation to achieve a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives, prerequisites, or contextual constraints. While it implies usage for pending upgrades, it doesn't specify conditions like governance approval status or timing, leaving the agent with insufficient usage context.

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

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

No annotations are provided, so the description carries full burden. While 'Check' implies a read operation, the description doesn't disclose important behavioral aspects like whether this requires authentication, what format the information is displayed in, whether it's cached or real-time data, or potential rate limits. For a tool with zero annotation coverage, this is insufficient.

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

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

The description is perfectly concise - a single sentence that efficiently communicates the tool's purpose without any wasted words. It's front-loaded with the core functionality ('Check if the current network is testnet') followed by the additional outcome ('display testnet information').

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

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

For a zero-parameter tool with no output schema, the description provides the basic purpose but lacks important context. Without annotations or output schema, the description should ideally specify what 'testnet information' includes (e.g., network ID, chain parameters, status indicators) and how it's presented. The current description is minimally adequate but leaves gaps.

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

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

The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't waste space discussing non-existent parameters. It correctly focuses on the tool's purpose rather than parameter details that don't exist.

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

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

The description clearly states the tool's purpose with a specific verb ('Check') and resource ('current network'), and indicates it will 'display testnet information'. However, it doesn't explicitly differentiate this tool from sibling tools like 'get-testnet-tokens' or 'get-blockchain-status', which might also provide testnet-related information.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that might provide overlapping network status information (like 'get-blockchain-status'), there's no indication of when this specific testnet check is appropriate versus other network query tools.

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

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

No annotations are provided, so the description carries full burden. It mentions 'Claim rewards' which implies a write/mutation operation, but fails to disclose critical behavioral traits like authentication requirements (beyond mnemonic in schema), potential fees, transaction finality, or error conditions. This is inadequate for a tool that likely modifies blockchain state.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary elaboration. Every word earns its place, making it optimally concise for the tool's complexity.

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

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after claiming (e.g., reward distribution, confirmation), error scenarios, or dependencies. Given the complexity of blockchain transactions, more context is needed for safe usage.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline expectation but not providing extra value.

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

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

The description clearly states the specific action ('Claim rewards') and target resource ('from the community pool'), with additional precision specifying it's for 'validator commission'. This distinguishes it from sibling tools like 'claim-incentives' or 'get-validator-commission', 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.

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

No guidance is provided on when to use this tool versus alternatives. While it mentions 'validator commission', it doesn't clarify prerequisites, timing considerations, or how it differs from other reward-claiming tools in the sibling list, leaving usage context implicit.

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

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

No annotations are provided, so the description carries full burden. It mentions 'claim' which implies a write/transaction operation, but doesn't disclose critical behavioral traits: whether this requires specific permissions, if it's irreversible, what happens on failure, or any rate limits. The description adds minimal context beyond the basic action.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core purpose. Every word earns its place in conveying the essential action.

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

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

For a transaction tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'claiming' entails operationally, what the expected outcome is, error conditions, or security implications. The 100% schema coverage helps with parameters but doesn't compensate for missing behavioral context.

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

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

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the action ('claim') and target ('available incentive rewards from locked tokens'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'claim-community-pool' or 'prepare-claim-rewards', which might have overlapping purposes in the same blockchain ecosystem.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to claiming, locking, and incentives in this server, there's no indication of prerequisites, timing, or distinctions from tools like 'claim-community-pool' or 'prepare-claim-rewards'.

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

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

No annotations are provided, so the description carries full burden. 'Create' implies a write/mutation operation, but the description doesn't disclose behavioral traits like authentication requirements (though mnemonic parameter hints at signing), potential side effects, transaction costs, error conditions, or what happens upon success. For a creation tool with zero annotation coverage, this is inadequate.

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

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

The description is maximally concise with a single 5-word sentence that states the core purpose. There's zero wasted language, and it's appropriately sized for what it communicates. The structure is straightforward and front-loaded with the essential information.

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

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

For a complex creation tool with 6 parameters (including sensitive mnemonic), no annotations, and no output schema, the description is severely incomplete. It doesn't explain what gets created, what the expected outcome is, error handling, or how this differs from other pool creation methods. The context demands much more comprehensive documentation.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples for instantiateMsg, or clarify dependencies. Baseline 3 is appropriate when schema does all the parameter documentation work.

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

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

The description 'Create a CosmWasm-based pool' clearly states the action (create) and resource (CosmWasm-based pool), but it's vague about what constitutes a 'pool' in this context and doesn't distinguish from sibling tools like 'create-pool' or 'prepare-cl-create-position'. It provides basic purpose but lacks specificity about the type of pool being created.

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

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

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'create-pool' and 'prepare-cl-create-position' available, there's no indication of when this CosmWasm-specific creation method is preferred, what prerequisites exist, or what scenarios warrant its use over other pool creation methods.

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

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

No annotations are provided, so the description carries full burden. While 'Create' implies a write/mutation operation, the description doesn't disclose important behavioral aspects: that this requires signing with a mnemonic (security implication), that it creates a blockchain transaction (with gas costs), or what happens on success/failure. For a tool with 9 parameters including sensitive mnemonic data, this is inadequate.

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

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

The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.

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

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

For a complex creation tool with 9 parameters (including sensitive mnemonic), no annotations, and no output schema, the description is insufficient. It doesn't explain what an 'incentive gauge' is in this context, what happens after creation, or any prerequisites. The description should provide more context given the tool's complexity and lack of supporting structured information.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score. However, it doesn't compensate for any gaps since there are none in the schema.

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

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

The description clearly states the action ('Create') and resource ('new incentive gauge for rewarding locked tokens'), providing a specific purpose. However, it doesn't differentiate from sibling tools like 'create-pool' or 'create-cosmwasm-pool', which also create resources but for different purposes.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools involving creation operations (create-pool, create-cosmwasm-pool), there's no indication of when this specific gauge creation tool is appropriate versus other creation tools.

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

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

With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose critical behavioral traits like whether this is a write operation (implied but not explicit), transaction costs, network requirements, error conditions, or what happens on success (e.g., returns pool ID). This is inadequate for a complex creation tool.

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

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

The description is a single, direct sentence with zero wasted words. It's perfectly front-loaded and appropriately sized for the tool's complexity, making it easy for an agent to parse quickly.

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

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

For a complex creation tool with 12 parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what the tool returns, error handling, or behavioral nuances, leaving significant gaps for the agent to infer or fail.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline but not providing extra value like examples or constraints not in the schema.

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

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

The description clearly states the action ('Create') and resource ('new liquidity pool on Osmosis'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'create-cosmwasm-pool' or other creation tools, which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'create-cosmwasm-pool' or other pool-related tools. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with insufficient context for selection.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'deposit tokens' which implies a write/mutation operation, but fails to disclose critical behaviors: that this requires signing with a mnemonic (a security-sensitive action), that it involves blockchain transaction costs (gas), or what happens on success/failure. This leaves significant gaps for agent understanding.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point without unnecessary elaboration.

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

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

For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after deposit (e.g., proposal status changes, return values, error conditions), nor does it cover security implications of using a mnemonic. Given the complexity of blockchain transactions and 7 parameters, more context is needed for agent effectiveness.

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

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

Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain the relationship between 'amount' and 'denom' or clarify that 'uosmo' is the base denomination). Baseline 3 is appropriate when the schema does all the work.

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

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

The description clearly states the action ('deposit tokens') and target ('to a governance proposal'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'vote-proposal' or 'submit-proposal' that also interact with governance proposals, which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'vote-proposal' or 'submit-proposal', nor does it mention prerequisites such as needing a valid proposal ID or sufficient token balance. It simply states what the tool does without contextual usage information.

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

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

No annotations are provided, so the description carries the full burden. It states the action ('derives') but doesn't disclose behavioral traits like whether this is a read-only computation, if it requires network access, potential errors (e.g., invalid key format), or output format. The description is minimal and lacks necessary context for safe use.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple tool, though it could be more informative. No structural issues, but it's borderline under-specified rather than concise.

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

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the derived address looks like (e.g., format, encoding), potential use cases, or error conditions. For a tool with 2 parameters and cryptographic operations, this leaves significant gaps for an AI agent.

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

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

Schema description coverage is 100%, so the schema fully documents the two parameters ('publicKey' and 'prefix'). The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain the derivation algorithm or prefix usage). Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description 'Derives an address from a public key' clearly states the verb ('derives') and resource ('address'), but it's vague about what type of address (e.g., blockchain address) and doesn't distinguish from sibling tools like 'get-wallet-address' or 'validate-address'. It's functional but lacks specificity.

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

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools include 'get-wallet-address' and 'validate-address', but the description doesn't clarify if this is for generating new addresses, validating existing ones, or other contexts. Usage is implied only by the tool name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Estimates gas fees', implying a read-only, non-destructive operation, but doesn't clarify if it simulates execution, requires network connectivity, has rate limits, or returns specific fee details. For a tool with no annotations, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a tool with good schema coverage. Every word earns its place without redundancy.

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

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

Given the tool's complexity (contract execution estimation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the estimation returns (e.g., fee amount, units), potential errors, or dependencies. For a tool with behavioral and output uncertainties, more context is needed.

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

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

Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain the format of 'executeMsg' or 'funds'). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

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

The description clearly states the tool's purpose with a specific verb ('Estimates') and resource ('gas fees for contract execution'). It distinguishes from some siblings like 'estimate-instantiate-fee' (for instantiation) and 'estimate-swap' (for swaps), but doesn't explicitly differentiate from all fee-related tools. The purpose is clear but could be more specific about scope.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, related tools (e.g., 'prepare-execute-contract'), or scenarios where estimation is needed. Without usage context, the agent must infer when this tool is appropriate.

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

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

No annotations are provided, so the description carries the full burden. It states the tool 'estimates' fees, implying a read-only, non-destructive operation, but doesn't disclose behavioral traits like whether it requires network connectivity, has rate limits, returns specific error conditions, or if it's a simulation that doesn't affect blockchain state. More context is needed for a mutation-adjacent tool.

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for its purpose, earning full marks for conciseness.

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

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

Given the tool's moderate complexity (4 parameters, nested objects, no output schema), the description is minimal but functional. It states what the tool does, but without annotations or output schema, it lacks details on behavioral context, return values, or error handling, making it adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain parameter relationships or usage examples). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the verb ('estimates') and resource ('gas fees for contract instantiation'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'estimate-execute-fee' or 'prepare-instantiate-contract', which would be needed for a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'estimate-execute-fee' and 'prepare-instantiate-contract' available, there's no indication of whether this is for planning, simulation, or cost estimation before actual instantiation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'estimates' but does not clarify if this is a read-only operation, whether it requires network access, potential rate limits, or error conditions. This leaves significant gaps in understanding 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.

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

The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration, earning a top score for brevity and structure.

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

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

Given the complexity of a swap estimation tool with no annotations and no output schema, the description is insufficient. It does not explain what the estimation includes (e.g., output amount, fees, slippage) or the format of the result, leaving the agent without enough information to understand the tool's full context and usage.

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

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

The input schema has 100% description coverage, documenting all four parameters clearly. The description adds no additional semantic context beyond what the schema provides, such as example values or interdependencies between parameters. Thus, it meets the baseline score of 3, as the schema adequately handles parameter documentation.

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

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

The description 'Estimates the result of a token swap' clearly states the verb ('estimates') and resource ('token swap'), making the purpose understandable. However, it lacks specificity about what 'result' means (e.g., output amount, fees, slippage) and does not distinguish it from sibling tools like 'get-cl-swap-estimates' or 'prepare-swap-transaction', leaving room for ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing pool or token data, or compare it to related tools like 'get-cl-swap-estimates' for estimates or 'prepare-swap-transaction' for actual swaps, leaving the agent without context for tool selection.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'Exit pool' which implies a destructive write operation (burning LP shares), but fails to detail critical aspects like transaction signing requirements (implied by 'mnemonic' parameter), potential gas costs, rate limits, or error conditions. The description is too sparse for a tool with significant financial implications.

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

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

The description is a single, front-loaded sentence that directly states the tool's purpose without any fluff. It is appropriately sized and efficiently communicates the core functionality, earning a high score for conciseness.

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

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

Given the complexity (7 parameters including sensitive mnemonic, no output schema, and no annotations), the description is inadequate. It does not explain the transaction nature, return values, error handling, or security considerations, leaving significant gaps for a tool that performs financial operations in a blockchain context.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying the 'tokenOut' parameter specifies the exact amount to receive, which is already clear from the schema. This meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Exit pool') and specifies the exact input condition ('by specifying exact token amount to receive'), which distinguishes it from generic exit operations. However, it does not explicitly differentiate from its sibling 'exit-swap-share-amount-in', which likely handles a different input parameter (share amount vs. token amount), so it falls short of a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'exit-swap-share-amount-in' or other exit-related tools in the sibling list. It lacks context about prerequisites, typical scenarios, or exclusions, leaving the agent with minimal usage direction.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action (exit pool by burning shares) but lacks critical details: it doesn't mention that this is a write operation requiring a mnemonic for signing, potential transaction fees (implied by gas parameters), irreversible effects of burning shares, or what happens to the received tokens. For a tool with 8 parameters including sensitive data like mnemonics, this is insufficient.

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and mechanism, making it easy to parse quickly without unnecessary elaboration.

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

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

Given the tool's complexity (8 parameters including sensitive mnemonic, no annotations, no output schema), the description is inadequate. It doesn't cover behavioral aspects like transaction signing, irreversibility, or output expectations, leaving significant gaps for a tool that performs a critical financial operation (exiting a liquidity pool).

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

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

Schema description coverage is 100%, providing clear documentation for all 8 parameters. The description adds minimal value beyond the schema, only implying the purpose of 'shareInAmount' (exact LP shares to burn) without explaining parameter interactions or additional context. Baseline 3 is appropriate as the schema handles most semantics.

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

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

The description 'Exit pool by burning exact LP shares' clearly states the action (exit pool) and mechanism (burning exact LP shares), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'exit-swap-extern-amount-out' or 'prepare-exit-pool', which appear to serve similar exit functions with different parameters or contexts.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing LP shares), exclusions, or comparisons to sibling tools like 'exit-swap-extern-amount-out' or 'prepare-exit-pool', leaving the agent without context for selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'admin only', indicating authorization needs, but lacks details on destructive effects (e.g., irreversible transfer), rate limits, or response behavior. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is extremely concise with a single phrase, front-loaded with the key action and constraint. There is zero waste, making it efficient and easy to parse, though it may be overly brief for such a complex tool.

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

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

Given the tool's complexity (admin-only mutation with 8 parameters), no annotations, and no output schema, the description is inadequate. It lacks details on behavioral traits, error handling, or return values, leaving significant gaps for an agent to understand and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the 'force' aspect or interactions between parameters. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the action ('force transfer tokens') and specifies the resource ('tokens'), making the purpose explicit. It distinguishes from siblings by indicating it's an admin-only operation, which is unique among the listed tools, though it doesn't explicitly contrast with similar transfer tools like 'send' or 'multi-send' beyond the admin aspect.

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

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

The description implies usage context by stating 'admin only', suggesting it's for privileged operations, but it doesn't explicitly state when to use this tool versus alternatives like 'send' or 'multi-send'. No exclusions or specific scenarios are provided, leaving the guidance at an implied level.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Fund the community pool with tokens' implies a write operation that transfers tokens, but it doesn't disclose critical behaviors like whether this requires specific permissions, is irreversible, has rate limits, or what happens on success/failure. The description is minimal and lacks necessary 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.

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point without unnecessary elaboration.

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

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

For a tool that performs a financial transaction (funding a community pool) with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after funding, potential side effects, error conditions, or return values. The combination of a mutation tool with minimal description and no structured behavioral metadata creates significant gaps for an agent.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema descriptions (e.g., mnemonic for signing, amount structure, gas defaults). This meets the baseline expectation when schema coverage is complete.

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

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

The description 'Fund the community pool with tokens' clearly states the action (fund) and target resource (community pool). It's specific enough to understand the core function, though it doesn't explicitly differentiate from sibling tools like 'claim-community-pool' which might perform the opposite operation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare it to sibling tools like 'claim-community-pool' or 'send' that might handle similar token transfers.

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

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

No annotations are provided, so the description carries full burden. It states the tool generates a wallet with a mnemonic phrase but doesn't disclose critical behavioral aspects like whether this creates a persistent wallet, requires authentication, has rate limits, or what happens to existing wallets. For a wallet generation tool with zero annotation coverage, this is insufficient.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

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

Given the complexity of wallet generation (a security-sensitive operation) with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., mnemonic, address, private key), security implications, or error conditions, leaving significant gaps for an AI agent to understand the tool's full context.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters (wordCount and prefix). The description adds no additional parameter semantics beyond what's in the schema, such as explaining why these parameters matter or their implications. Baseline 3 is appropriate when the schema does all the work.

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

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

The description clearly states the action ('Generates') and resource ('new Osmosis wallet with mnemonic phrase'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'restore-wallet-from-mnemonic' or 'get-wallet-address', which would be needed for a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'restore-wallet-from-mnemonic' and 'get-wallet-address' available, there's no indication of when generation is appropriate versus restoration or retrieval, leaving usage context unclear.

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

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

No annotations are provided, so the description carries full burden. While 'Returns' implies a read-only operation, it doesn't disclose important behavioral aspects like whether this requires authentication, rate limits, error conditions, or what format the balances are returned in. For a query tool with zero annotation coverage, this is inadequate.

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

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

The description is a single, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a simple query tool and front-loads the essential information.

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

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

For a simple read operation with one well-documented parameter, the description is minimally adequate. However, without annotations or output schema, it doesn't provide enough context about what the return data looks like or any behavioral constraints. The description does the bare minimum for this level of complexity.

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

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

Schema description coverage is 100%, with the single parameter 'address' clearly documented in the schema. The description adds no additional parameter information beyond what the schema already provides, so it meets the baseline score when schema coverage is complete.

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

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

The description clearly states the verb ('Returns') and resource ('token balances for an Osmosis address'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools that also query data (like get-pool-info or get-validators), so it doesn't reach the highest score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling query tools available (e.g., get-pool-info, get-validators), there's no indication of when this specific balance query is appropriate or what distinguishes it from other data retrieval tools.

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

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

No annotations are provided, so the description carries the full burden. It only mentions returning filtered information, without disclosing behavioral traits like pagination, rate limits, permissions needed, or what 'lock information' entails (e.g., format, fields). This is inadequate for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence with zero waste, front-loading the core action and filter. It's appropriately sized for its simple purpose, making it easy to parse quickly.

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

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'lock information' includes, potential errors, or behavioral context, leaving gaps for an AI agent to understand the tool's full operation in this complex blockchain environment.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (lockType with enum, address as optional). The description adds no additional meaning beyond implying filtering by type, which is already covered. Baseline 3 is appropriate as the schema handles parameter semantics effectively.

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

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

The description clearly states the verb ('Returns') and resource ('lock information') with a specific filter ('by lock type'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-lockups' or 'get-synthetic-locks-by-lock-id', which might also retrieve lock-related data, so it misses full sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as other lock-related tools in the sibling list. It lacks context on prerequisites, exclusions, or comparisons, leaving usage ambiguous beyond the basic filter stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Returns information' but doesn't clarify if this is a read-only operation, what permissions are needed, if there are rate limits, or the format of the returned data. This is inadequate for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.

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

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

Given the lack of annotations and output schema, the description is insufficient. It doesn't explain the return format, potential errors, or behavioral traits like pagination or data scope. For a tool in a complex ecosystem with many siblings, more context is needed to guide the agent effectively.

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

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

The input schema has 100% description coverage, documenting the optional 'limit' parameter with its default. The description adds no parameter semantics beyond this, so it meets the baseline score of 3, as the schema handles the parameter documentation adequately.

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

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

The description clearly states the verb ('Returns') and resource ('information about all liquidity pools'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-cl-pools' or 'get-pool-info', which appear to serve similar purposes but with different scopes or parameters.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to pools (e.g., 'get-cl-pools', 'get-pool-info', 'get-pool-liquidity'), the description lacks context on distinctions, prerequisites, or exclusions, leaving the agent to infer usage.

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

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

No annotations are provided, so the description carries the full burden. It states it 'Returns' data, implying a read-only operation, but doesn't disclose any behavioral traits such as rate limits, authentication needs, error conditions, or what 'status' entails (e.g., uptime, network health, sync state). This leaves significant gaps for an agent to understand how to use it effectively.

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

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

The description is a single, clear sentence with no wasted words. It is front-loaded with the core purpose and efficiently communicates what the tool does without unnecessary elaboration.

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

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

Given the tool has 0 parameters and no output schema, the description is minimally adequate but lacks depth. It doesn't explain what 'status' includes (e.g., block height, validator set, network conditions), which could be crucial for an agent to interpret results. With no annotations and many sibling tools, more context would improve completeness.

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

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

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is given since the schema fully covers the absence of parameters, and the description doesn't need to compensate.

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

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

The description clearly states the verb ('Returns') and resource ('current status of the Osmosis blockchain'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-chain-params' or 'get-latest-blocks', which also provide blockchain-related information, so it doesn't reach the highest score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that retrieve blockchain data (e.g., 'get-chain-params', 'get-latest-blocks'), there is no indication of what specific status information this tool provides or when it should be preferred over others.

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

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

No annotations are provided, so the description carries the full burden. It states it 'returns' data, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, error conditions, or response format. This is inadequate for a tool with no annotation support.

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

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

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

Given the tool's low complexity (one optional parameter) and high schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it lacks details on return values or behavioral context, making it incomplete for full understanding.

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

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

The input schema has 100% description coverage, documenting the optional 'module' parameter with its enum values. The description doesn't add any parameter semantics beyond the schema, so it meets the baseline of 3 for high schema coverage without compensating value.

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

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

The description clearly states the action ('Returns') and resource ('current chain parameters for the Osmosis blockchain'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get-distribution-params' or 'get-mint-params', which are more specific parameter queries, so it misses the top score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools querying specific parameters (e.g., 'get-distribution-params'), there's no indication if this is a general-purpose tool or how it relates to them, leaving usage unclear.

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

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

No annotations are provided, so the description carries full burden. It states 'Returns' which implies a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns real-time or historical data, or error conditions. This is a significant gap for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple retrieval tool and front-loaded with the core purpose, making it easy to parse quickly.

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

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

Given the tool's low complexity (one parameter, no output schema) and high schema coverage, the description is minimally adequate. However, without annotations or output schema, it lacks details on return format (e.g., what statistics are included, data structure), leaving gaps in completeness for effective agent use.

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

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

The input schema has 100% description coverage, clearly documenting the single required parameter 'poolId'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 where the schema does the heavy lifting.

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

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

The description clearly states the action ('Returns') and resource ('fee growth statistics for a CL pool'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-cl-pool-incentives' or 'get-cl-pool-liquidity' that also retrieve CL pool data, missing explicit distinction.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools for CL pools (e.g., 'get-cl-pool-incentives', 'get-cl-pool-liquidity'), the description lacks context on specific use cases or prerequisites, leaving the agent to infer based on the name alone.

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

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

No annotations are provided, so the description carries the full burden. It states the tool returns information, implying it's a read operation, but doesn't disclose behavioral traits such as rate limits, authentication needs, or what 'incentive information' entails (e.g., format, scope). This is a significant gap for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse without unnecessary elaboration.

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

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'incentive information' includes (e.g., data structure, units) or behavioral aspects like error handling, leaving gaps for the agent to operate effectively in this context.

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

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

The input schema has 100% description coverage, with 'poolId' clearly documented. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.

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

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

The description states the tool's purpose ('Returns incentive information for a CL pool') with a clear verb ('Returns') and resource ('incentive information for a CL pool'), but it doesn't differentiate from sibling tools like 'get-pool-incentives' or 'get-incentivized-pools', making it somewhat vague in context.

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

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

No guidance is provided on when to use this tool versus alternatives. With siblings like 'get-pool-incentives' and 'get-incentivized-pools', the description lacks context or exclusions, leaving the agent to infer usage based on the name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Returns' data, implying a read-only operation, but doesn't specify if it's safe, has rate limits, requires authentication, or what the output format might be. This is a significant gap for a tool with no structured safety hints.

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

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

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

Given the complexity of a liquidity query tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return values, potential errors, or behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.

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

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

The input schema has 100% description coverage, clearly documenting all parameters. The description adds no additional meaning beyond the schema, such as explaining what 'liquidity depth and distribution' entails or how tick bounds affect the query. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the action ('Returns') and resource ('liquidity depth and distribution for a CL pool'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-pool-liquidity' or 'get-cl-pool-tick-data', which might have overlapping functionality, so it doesn't reach the highest score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to pools and liquidity, there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on the name alone.

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

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

No annotations are provided, so the description carries full burden. It states a read operation ('Returns') but doesn't disclose behavioral traits like pagination, rate limits, permissions needed, or what 'all' means in practice (e.g., if it's paginated or a complete dump). This is inadequate for a tool with potential complexity.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain return values, behavioral constraints, or how it differs from sibling tools. For a tool that likely returns complex data (pools), this leaves significant gaps for an agent.

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

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

Schema description coverage is 100%, so the schema fully documents the single optional parameter 'limit'. The description adds no parameter semantics beyond what the schema provides, but with high coverage, the baseline is 3 as the schema does the heavy lifting.

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

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

The description clearly states the verb ('Returns') and resource ('all Concentrated Liquidity pools'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-all-pools' or 'get-cl-positions', which could cause confusion about scope.

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

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

No guidance is provided on when to use this tool versus alternatives like 'get-all-pools' or 'get-cl-positions-by-pool'. The description lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Returns' implies a read-only operation, it doesn't specify whether this is a real-time query, cached data, or has any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational 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.

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

The description is a single, efficient sentence that directly states what the tool does without any unnecessary words. It's appropriately sized for a simple query tool and front-loads the essential information. Every word earns its place in conveying the core functionality.

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

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

For a simple query tool with one parameter and no output schema, the description adequately covers the basic purpose. However, without annotations or output schema, it doesn't provide enough context about what specific tick data is returned (e.g., format, units, or structure) or any behavioral constraints. The description is minimally complete but lacks depth for confident tool selection.

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

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

The input schema has 100% description coverage, with the single parameter 'poolId' clearly documented in the schema. The description doesn't add any additional meaning about the parameter beyond what's in the schema. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description.

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

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

The description clearly states the verb ('Returns') and the specific resources ('tick spacing and current tick for a CL pool'), making the purpose unambiguous. It distinguishes itself from other 'get-cl-pool-*' tools by focusing on tick data rather than liquidity, incentives, or positions. However, it doesn't explicitly differentiate from all possible siblings beyond the naming pattern.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'get-cl-pool-liquidity', 'get-cl-pool-incentives', and 'get-cl-pools', there's no indication of when tick data is needed versus other pool metrics. No prerequisites, exclusions, or contextual alternatives are mentioned.

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

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

No annotations are provided, so the description carries full burden. It states it 'Returns details' but lacks behavioral context such as whether it's a read-only operation, error handling for invalid IDs, performance expectations, or authentication needs. This is a significant gap for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate but lacks completeness. It does not explain return values, error cases, or behavioral traits, which are needed for full contextual understanding despite the simple schema.

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

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

The input schema has 100% description coverage, with 'positionId' clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the verb ('Returns') and resource ('details of a specific Concentrated Liquidity position'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get-cl-positions' (plural) or 'get-cl-user-positions', which might retrieve multiple positions, leaving some ambiguity in sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context for selecting a specific position, or comparisons with sibling tools like 'get-cl-positions' or 'get-cl-user-positions', leaving the agent without usage direction.

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

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

No annotations are provided, so the description carries the full burden. It states this is a read operation ('Returns'), which implies it's non-destructive, but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, error conditions, or what 'Concentrated Liquidity positions' entails in terms of data structure or format.

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

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

The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the tool's function without unnecessary elaboration.

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

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

Given the tool's simplicity (one parameter, no annotations, no output schema), the description is minimally adequate. It states what the tool does but lacks context on usage versus siblings, behavioral details, or output format, leaving gaps for an AI agent to infer correctly.

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

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

Schema description coverage is 100%, with the single parameter 'address' well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as address format examples or validation rules, so it meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Returns') and resource ('Concentrated Liquidity positions for an address'), making the purpose understandable. However, it doesn't distinguish this tool from similar sibling tools like 'get-cl-position' (singular) or 'get-cl-user-positions', which might cause confusion about scope or differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'get-cl-position' (singular) and 'get-cl-user-positions', the description lacks context on whether this tool returns all positions for an address, filtered results, or how it differs from other position-related tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Returns') but doesn't mention any behavioral traits such as pagination, rate limits, authentication needs, or what 'positions' entail. This leaves significant gaps for a tool with potential complexity.

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

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness.

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

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'positions' are, the return format, or any behavioral context. For a tool in a complex domain (CL pools) with many siblings, more detail is needed to ensure the agent can use it effectively.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (poolId and limit). The description adds no additional meaning beyond implying a pool-specific query, which is already covered by the schema. Baseline score of 3 is appropriate as the schema handles parameter semantics adequately.

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

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

The description clearly states the action ('Returns') and resource ('all positions in a specific CL pool'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-cl-positions' or 'get-cl-user-positions', which likely have overlapping functionality, so it misses full sibling distinction.

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

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

No guidance is provided on when to use this tool versus alternatives like 'get-cl-positions' or 'get-cl-user-positions'. The description lacks context about prerequisites, exclusions, or comparisons, leaving the agent with no usage direction beyond the basic purpose.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns estimates, implying a read-only operation, but does not cover aspects like rate limits, error conditions, or what 'price impact' entails in terms of output format or calculation. This leaves significant gaps in understanding 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.

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

The description is a single, efficient sentence that front-loads the key information ('Returns swap estimates') without any wasted words. It is appropriately sized for its purpose, making it easy to parse quickly.

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

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

Given the complexity of swap estimation with price impact, no annotations, and no output schema, the description is incomplete. It does not explain what the estimates include, how price impact is calculated, or the format of the return values, leaving the agent with insufficient context to use the tool effectively.

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

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

The input schema has 100% description coverage, so the schema fully documents all five parameters. The description adds no additional meaning beyond what the schema provides, such as examples or context for parameter usage. With high schema coverage, the baseline score of 3 is appropriate as the description does not compensate but also does not detract.

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

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

The description clearly states the action ('Returns') and resource ('swap estimates specifically for CL pools with price impact'), making the purpose understandable. However, it does not explicitly distinguish this tool from sibling tools like 'estimate-swap' or 'get-cl-pool-liquidity', which might offer related functionality, so it lacks full sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'estimate-swap' or other CL pool tools in the sibling list. It mentions 'specifically for CL pools with price impact', but this is part of the purpose statement rather than explicit usage instructions or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns data but doesn't mention any behavioral traits such as rate limits, authentication needs, data freshness, or pagination. This leaves significant gaps in understanding how the tool behaves in practice.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

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

Given the tool's moderate complexity (querying user positions across pools) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but fails to address behavioral aspects or differentiate from siblings, leaving room for improvement in completeness.

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

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

The input schema has 100% description coverage, fully documenting both parameters ('address' and optional 'poolId'). The description adds no additional semantic context beyond what the schema provides, such as format examples or usage nuances, so it meets the baseline score for high schema coverage.

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

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

The description clearly states the action ('Returns') and resource ('all CL positions for a user across all pools'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get-cl-position' (singular) or 'get-cl-positions-by-pool', which might cause ambiguity in tool selection.

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

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

No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'get-cl-position' (singular position), 'get-cl-positions-by-pool' (positions filtered by pool), and 'get-cl-positions' (possibly similar), the description lacks explicit context or exclusions to help an agent choose correctly.

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

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

No annotations are provided, so the description carries the full burden. It states this is a read operation ('Returns'), implying it's non-destructive, but doesn't disclose any behavioral traits such as permissions needed, rate limits, error conditions, or what the metadata includes. For a tool with no annotations, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it could be slightly more front-loaded with more specific details, but overall it's well-structured for its brevity.

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

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what metadata is returned, potential errors, or how it differs from similar tools. For a tool in a complex ecosystem with many siblings, this leaves significant gaps for an AI agent to understand its full context.

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

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

The input schema has 100% description coverage, with one parameter 'codeId' clearly documented as 'The code ID to query'. The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.

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

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

The description 'Returns metadata for a WASM code' clearly states the action (returns) and resource (metadata for WASM code), but it's somewhat vague about what 'metadata' entails and doesn't differentiate from sibling tools like 'get-wasm-code-info' or 'get-wasm-codes' that might handle related WASM code queries.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to WASM/code (e.g., get-wasm-code-info, get-wasm-codes), the description lacks any context on prerequisites, distinctions, or exclusions, leaving the agent to infer usage.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a query operation ('Returns'), implying read-only behavior, but doesn't specify whether it requires authentication, has rate limits, what happens with invalid addresses, or the format of the returned admin address. For a query tool with zero annotation coverage, this leaves significant gaps.

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

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

The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple query tool and gets straight to the point.

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

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

For a simple single-parameter query tool with 100% schema coverage, the description is minimally adequate but lacks important context. Without annotations or output schema, it doesn't specify what format the admin address returns in, error conditions, or how this differs from similar contract query tools. The description meets basic requirements but leaves the agent guessing about important behavioral details.

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

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

The schema description coverage is 100%, so the schema already fully documents the single 'contractAddress' parameter. The description doesn't add any additional semantic context about the parameter beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the action ('Returns') and the specific resource ('the admin address of a contract'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'get-contract-info' or 'get-contract-label', but the specific focus on admin address provides some implicit distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'get-contract-info' (which might include admin address among other details) or other contract query tools. There's no mention of prerequisites, context, or comparison to sibling tools.

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

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

No annotations are provided, so the description carries full burden. It states it 'Returns' data, implying a read-only operation, but doesn't disclose behavioral traits like permissions needed, rate limits, error conditions, or what 'code ID' represents. For a tool with zero annotation coverage, this is insufficient.

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

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose, making it easy to parse quickly, which is ideal for a simple query tool.

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

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what a 'code ID' is, the return format, or any behavioral context. For a tool in a complex blockchain environment with many siblings, this leaves significant gaps for an agent to operate effectively.

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

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

The input schema has 100% description coverage, documenting the single parameter 'contractAddress' clearly. The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating value.

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

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

The description clearly states the action ('Returns') and the specific resource ('the code ID of a contract'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'get-contract-info' or 'get-code-metadata', but it's unambiguous about what it retrieves.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools querying contract-related data (e.g., 'get-contract-info', 'get-contract-admin', 'get-contract-label'), the description lacks context for selection, leaving the agent to infer based on tool names alone.

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

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

No annotations are provided, so the description carries the full burden. It mentions 'Returns events' but does not disclose behavioral traits such as whether this is a read-only operation, if it requires specific permissions, rate limits, pagination, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's purpose, making it highly concise and well-structured for quick understanding.

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

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

Given the complexity of querying contract events in a blockchain context, no annotations, and no output schema, the description is incomplete. It does not explain what 'events' entail (e.g., logs, transactions), return format, or error scenarios. For a tool with 3 parameters and rich sibling tools, more context is needed to be fully helpful.

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

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

Schema description coverage is 100%, so the input schema fully documents the parameters (contractAddress, eventType, limit). The description does not add any meaning beyond what the schema provides, such as explaining event types or default behaviors. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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

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

The description states the tool 'Returns events emitted by a contract', which clearly indicates the action (returns) and resource (contract events). However, it lacks specificity about what types of events or how they differ from other contract-related tools like 'get-contract-history' or 'get-contract-info', making it vague in sibling differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools like 'get-contract-history' and 'get-contract-info', the description does not specify if this is for real-time events, historical logs, or how it relates to other contract queries, leaving usage unclear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Returns') but does not specify whether this is a read-only operation, if it requires authentication, what the return format looks like, or any rate limits. For a tool with no annotations, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence with zero waste. It is front-loaded and directly states the tool's purpose without unnecessary elaboration, making it highly concise and well-structured.

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

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

Given the lack of annotations and no output schema, the description is incomplete. It does not explain what 'code migration history' entails (e.g., format, data points) or behavioral aspects like error handling. For a tool in a complex blockchain context with many siblings, more context is needed to guide the agent effectively.

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

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

The input schema has 100% description coverage, with the parameter 'contractAddress' clearly documented. The description does not add any additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline score of 3 where the schema does the heavy lifting.

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

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

The description clearly states the verb ('Returns') and resource ('code migration history of a contract'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get-contract-info' or 'get-contract-events', which might also provide contract-related information, so it falls short of a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'get-contract-info', 'get-contract-events'), there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.

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

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

No annotations are provided, so the description carries the full burden. It states this is a query operation ('Returns'), implying it is read-only, but does not disclose behavioral traits like error conditions, rate limits, or what happens if the contract lacks IBC capabilities. This is a significant gap for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary details, earning a high score for conciseness.

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

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

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on usage, behavior, or output, leaving gaps that could hinder an AI agent in selecting and invoking it correctly in all contexts.

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

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

The input schema has 100% description coverage, with the single parameter 'contractAddress' fully documented. The description does not add any meaning beyond the schema, such as format examples or constraints, so it meets the baseline score of 3 where the schema does the heavy lifting.

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

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

The description clearly states the verb ('Returns') and resource ('IBC port ID for contracts with IBC capabilities'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get-contract-info' or 'get-contract-admin', which might also query contract-related information, so it misses full sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a contract with IBC capabilities, or compare it to other contract query tools in the sibling list, leaving usage context implied at best.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Returns metadata' implies a read-only operation, it doesn't specify what kind of metadata is included, whether there are rate limits, authentication requirements, error conditions, or response format. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple query tool and front-loads the essential information ('Returns metadata about a specific contract').

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

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

For a simple single-parameter query tool with no output schema, the description provides the basic purpose but lacks important context. Without annotations, it should clarify what 'metadata' includes, any behavioral constraints, and how this differs from other contract query tools. The description is minimally adequate but leaves gaps that could confuse an agent about what to expect.

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

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

The input schema has 100% description coverage, with the single parameter 'contractAddress' clearly documented as 'The contract address to query'. The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage, resulting in the baseline score of 3.

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

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

The description clearly states the verb ('Returns') and resource ('metadata about a specific contract'), making the purpose unambiguous. However, it doesn't distinguish this tool from similar sibling tools like 'get-contract-admin', 'get-contract-code-id', or 'get-contract-label', which all return specific aspects of contract information rather than general metadata.

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

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

The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools that query contract-related information (e.g., 'get-contract-admin', 'get-contract-events', 'get-contract-history'), there's no indication whether this tool returns comprehensive metadata or just basic information, or when to choose it over more specific contract query tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Returns the label', implying a read-only operation, but does not specify if it requires authentication, has rate limits, or what the output format looks like. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is extremely concise ('Returns the label of a contract'), consisting of a single sentence that directly states the tool's function. There is no wasted language, making it front-loaded and efficient, though this conciseness comes at the cost of completeness.

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

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

Given the lack of annotations and output schema, the description is incomplete. It does not explain what a 'label' is, how it differs from other contract attributes, or what the return value entails. For a tool in a complex ecosystem with many siblings, this minimal description fails to provide sufficient context for effective use.

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

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

The input schema has 100% description coverage, with the parameter 'contractAddress' clearly documented. The description does not add any additional meaning beyond the schema, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

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

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

The description states the tool's purpose ('Returns the label of a contract'), which is clear but vague. It specifies the verb ('Returns') and resource ('label of a contract'), but does not explain what a 'label' is in this context or how it differs from similar tools like 'get-contract-info' or 'get-contract-admin'. This makes it minimally adequate but lacking specificity.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to contracts (e.g., 'get-contract-info', 'get-contract-admin', 'get-contract-events'), there is no indication of when this specific tool is appropriate, leaving the agent to guess based on the name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'returns all contracts' but does not clarify if this is a read-only operation, potential rate limits, pagination behavior, or error conditions. This leaves significant gaps in understanding how the tool behaves beyond its basic function.

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

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

The description is a single, direct sentence with no wasted words, efficiently conveying the core function. It is appropriately sized and front-loaded, making it easy to understand quickly.

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

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

Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, or output format, which would be needed for full completeness in a query tool.

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

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

The input schema has 100% description coverage, documenting both parameters ('codeId' and 'limit') clearly. The description adds no additional semantic context beyond what the schema provides, such as format details or usage examples, so it meets the baseline for adequate but unenhanced parameter documentation.

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

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

The description clearly states the action ('Returns') and resource ('all contracts instantiated from a specific code ID'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get-contract-info' or 'get-contract-code-id', which reduces it from a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as other contract-related tools in the sibling list. It lacks any mention of prerequisites, context, or exclusions, leaving usage unclear.

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

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

No annotations are provided, so the description carries the full burden. It states it 'Returns delegation information' but doesn't disclose behavioral traits such as whether it's a read-only operation, potential rate limits, authentication needs, error conditions, or the format of the returned information. This leaves significant gaps for an agent to understand how to invoke it effectively.

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

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to the tool's purpose.

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

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

Given the complexity implied by the sibling tools (e.g., various delegation-related tools) and the lack of annotations and output schema, the description is incomplete. It doesn't specify what type of delegation information is returned, how it differs from similar tools, or any behavioral context, leaving the agent with insufficient information to use it correctly in a rich ecosystem.

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

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

The input schema has 100% description coverage, with one parameter 'delegatorAddress' documented as 'The delegator address'. The description adds no additional meaning beyond this, as it doesn't explain what a delegator address is, provide examples, or clarify its role. With high schema coverage, the baseline score of 3 is appropriate, but no extra value is added.

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

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

The description 'Returns delegation information for an address' clearly states the verb ('Returns') and resource ('delegation information'), but it's vague about what specific delegation information is returned (e.g., delegations from, delegations to, amounts, status). It doesn't distinguish from siblings like 'get-validator-delegations' or 'get-unbonding-delegations', which are related but potentially different in scope.

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

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-validator-delegations' and 'get-unbonding-delegations', it's unclear if this tool is more general, specific to a certain type of delegation, or serves a different purpose entirely. No context or exclusions are mentioned.

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

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

With no annotations provided, the description carries full burden but offers minimal behavioral context. It states it 'returns all' but doesn't clarify if this is paginated, rate-limited, requires authentication, or what format the return data takes. For a query tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.

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

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

The description is a single, efficient sentence that directly states the tool's function without any unnecessary words. It's perfectly front-loaded and wastes no space, making it ideal for quick comprehension.

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

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

For a simple query tool with one well-documented parameter and no output schema, the description is minimally adequate but lacks important context. It doesn't explain what 'denoms' are in this context, what the return structure looks like, or any behavioral constraints. With no annotations and no output schema, more completeness would be beneficial.

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

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

Schema description coverage is 100%, so the schema already fully documents the single 'creator' parameter. The description adds no additional parameter semantics beyond what's in the schema (e.g., address format, validation rules, or examples). Baseline 3 is appropriate when the schema does all the work.

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

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

The description clearly states the action ('Returns') and resource ('all token factory denoms created by an address'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get-token-factory-denoms' or 'get-token-factory-creator', but the specificity about filtering by creator address provides implicit distinction.

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

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

No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage when you need denoms filtered by creator, but it doesn't mention prerequisites, limitations, or when other tools like 'get-token-factory-denoms' might be more appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('returns'), implying it's likely non-destructive and read-only, but doesn't confirm this or add other traits like authentication needs, rate limits, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('returns') and resource, making it easy to parse quickly. Every word earns its place by conveying the essential purpose.

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

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

Given the tool has 0 parameters and no output schema, the description is minimally complete for a simple read operation. However, with no annotations and many similar sibling tools, it lacks context about what 'distribution module parameters' entail or how this differs from other parameter-fetching tools, leaving some ambiguity for the agent.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required by not mentioning any. This meets the baseline for tools with no parameters.

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

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

The description 'Returns the distribution module parameters' clearly states the verb ('returns') and resource ('distribution module parameters'), making the purpose understandable. However, it doesn't differentiate from many similar 'get-' sibling tools (e.g., get-chain-params, get-mint-params, get-slashing-params) beyond specifying the module type, which is somewhat vague without context about what distribution entails.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools that fetch parameters (e.g., get-chain-params, get-mint-params), the description lacks any indication of context, prerequisites, or distinctions, leaving the agent to infer usage based on the name alone.

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

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

No annotations are provided, so the description carries the full burden. It states this is a read operation ('Returns'), implying it's non-destructive, but doesn't disclose any behavioral traits like permissions needed, rate limits, or what the return format looks like (e.g., JSON structure). This is a significant gap for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

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

Given the tool has 0 parameters and no output schema, the description is minimally complete for a simple read operation. However, it lacks details on return format or behavioral context, which would be helpful for an agent to understand what to expect from the output, especially without annotations.

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

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

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, earning a baseline score of 4 for adequately handling the lack of parameters.

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

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

The description clearly states the action ('Returns') and the resource ('downtime detector module parameters'), making the purpose understandable. It distinguishes itself from siblings like 'get-downtime-status' by focusing on parameters rather than status, though it could be more explicit about this differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify if this is for configuration checks, monitoring setup, or troubleshooting, leaving the agent to infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden. It states it 'returns' data, implying a read-only operation, but doesn't disclose behavioral traits such as rate limits, authentication needs, response format, or whether it queries real-time or cached data. This is inadequate for a tool with zero annotation coverage.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Returns current downtime status for the chain') with zero waste. Every word earns its place, making it highly concise and well-structured.

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

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

Given the complexity of chain monitoring and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'downtime status' includes (e.g., uptime percentage, outage details), response format, or how it differs from similar tools. For a tool in a crowded namespace, this leaves significant gaps.

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

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

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description correctly implies no inputs are required by focusing on the action and resource. A baseline of 4 is appropriate as it adds no unnecessary param info.

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

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

The description 'Returns current downtime status for the chain' clearly states the action (returns) and resource (downtime status for the chain), but it's somewhat vague about what 'downtime status' entails (e.g., binary indicator, detailed metrics, historical data). It doesn't differentiate from siblings like 'get-blockchain-status' or 'get-chain-params', which might overlap in monitoring chain health.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to chain status (e.g., 'get-blockchain-status', 'get-chain-params'), the description lacks context on specific use cases, prerequisites, or exclusions, leaving the agent to infer based on tool names alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns data, implying a read-only operation, but doesn't specify if it's real-time or cached, any rate limits, error conditions, or authentication needs. This leaves significant gaps in understanding how the tool behaves beyond its basic function.

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

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action ('Returns'), making it easy to parse quickly. Every part of the sentence contributes to understanding the purpose.

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

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

Given the tool has no parameters and no output schema, the description adequately covers the basic purpose. However, without annotations or output details, it lacks information on behavioral traits like performance, errors, or return format. For a simple read tool, this is minimally viable but leaves room for improvement in context.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is given since the schema fully handles parameters, and the description doesn't need to compensate for any gaps.

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

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

The description clearly states the verb ('Returns') and resource ('current epoch provisions for token minting'), making the tool's purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get-epochs' or 'get-mint-params', which might provide related but different information about epochs or minting parameters.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to epochs, minting, and provisions (e.g., 'get-epochs', 'get-mint-params'), there is no indication of context, prerequisites, or comparisons to help an agent decide when this specific tool is appropriate.

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

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

No annotations are provided, so the description carries full burden. 'Returns information' implies a read-only operation, but doesn't disclose behavioral traits like whether this is a heavy query, if there are rate limits, what format the information comes in, or if it requires authentication. The description provides minimal behavioral context beyond the basic operation.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple, parameterless query tool and gets straight to the point without unnecessary elaboration.

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

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

For a parameterless read operation with no annotations and no output schema, the description is minimally adequate. It states what the tool does but lacks important context about return format, data scope, or behavioral characteristics that would help an agent use it effectively.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4. The description correctly indicates this tool takes no parameters ('all epochs'), which aligns perfectly with the empty input schema. No additional parameter semantics are needed.

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

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

The description 'Returns information about all epochs' clearly states the action (returns) and resource (epochs), but is vague about what specific information is returned. It doesn't differentiate from sibling tools like 'get-epoch-provisions' or other get-* tools that might return different epoch-related data.

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

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

No guidance is provided about when to use this tool versus alternatives. With many sibling tools (over 100), including other epoch-related tools like 'get-epoch-provisions', the description offers no context about appropriate usage scenarios or distinctions.

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

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

No annotations are provided, so the description carries full burden. It states 'Returns list' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what format the list is in. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, earning full marks for conciseness.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks behavioral context and usage guidance, which are gaps given the many sibling tools. It's adequate but with clear room for improvement.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it doesn't, making it adequate. Baseline is 4 for 0 parameters as per rules.

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

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

The description 'Returns list of accepted fee payment tokens' clearly states the verb ('returns') and resource ('accepted fee payment tokens'), making the purpose understandable. However, it doesn't differentiate from siblings like 'get-testnet-tokens' or 'get-token-info', which also retrieve token-related data, so it's not fully specific to sibling context.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools like 'get-testnet-tokens' or 'get-token-info', the description lacks explicit context, prerequisites, or exclusions, leaving usage unclear.

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

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

No annotations are provided, so the description carries the full burden. It states the tool returns data but does not disclose behavioral traits like whether it's a read-only operation, potential rate limits, authentication needs, or error handling. This is a significant gap for a tool with multiple parameters and no output schema.

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

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

The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary details, earning its place.

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

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

Given the tool has 6 parameters, no annotations, and no output schema, the description is incomplete. It does not explain return values, error conditions, or behavioral context, making it inadequate for a data retrieval tool with this complexity.

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

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

Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional meaning beyond implying historical data retrieval, which is already covered by parameter descriptions. Baseline 3 is appropriate as the schema handles the heavy lifting.

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

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

The description clearly states the verb 'Returns' and resource 'historical price data for a token pair', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get-pool-spot-price' or 'get-twap', which might also provide price-related data, so it misses full sibling distinction.

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

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

No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as needing a valid poolId or token pair, and does not mention any exclusions or recommended scenarios, leaving usage unclear.

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