web3agent

by Apegurus

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.2
Disambiguation2/5
With 195 tools, there is substantial overlap between tool families (e.g., evm_get_balance, get_balance, and explorer_get_historical_balance; multiple token-resolution tools). Descriptions help in some cases, but the sheer number of near-synonymous operations makes misselection likely, especially across market, explorer, and EVM domains.
Naming Consistency2/5
Naming conventions are inconsistent: some tools use snake_case with domain prefixes (market_get_*), others use bare verbs (get_address, sign_message), and there are duplicate variants like convert_to_base_units vs convert_to_base_unit and get_token_allowance vs get_token_allowance_evm. This mix of patterns and redundant suffixes reduces predictability.
Tool Count1/5
195 tools is an extreme count that overwhelms rather than serves the user. Many tools are redundant or deprecated (see market_get_ticker), and the surface area is far too large for an agent to navigate effectively. Even for a broad web3 domain, this is excessive and poorly curated.
Completeness3/5
Core web3 workflows are covered: market data, contract interaction, wallet operations, swaps, bridges, and job protocols. However, there are notable gaps such as NFT transfers, contract deployment, and unified lifecycle management for some token operations. The presence of deprecated tools and duplicate implementations further muddies coverage.
Average 3.8/5 across 195 of 195 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- Last stable release on June 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only openWorldHint as an annotation, the description carries a heavy burden to disclose side effects (e.g., requiring wallet confirmation, returning a signature). It only repeats the function name. No behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. However, for a complex parameter set with nested objects, it is under-specified; the minimal structure does not adequately serve the agent's need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the one-line description does not explain the return value, chain selection behavior, or signing prerequisites. The tool is effectively underspecified for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only chainId has a description), and the tool description fails to mention any of the four required parameters (domain, types, primaryType, message) or their structure. The agent is left without guidance on how to construct the EIP-712 payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Sign' and a specific resource 'EIP-712 typed data structure (EVM)', making the core function clear. However, it does not explicitly distinguish from the near-identical sibling evm_sign_typed_data, 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.
Usage Guidelines2/5
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 evm_sign_message or evm_sign_typed_data. No exclusions, prerequisites, or contextual cues are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint, which does not clarify safety or side effects. The description says 'Fetch', implying read-only, but provides no additional behavioral context such as response format, rate limits, or error behavior. With no readOnly annotation, the description carries the burden but only offers minimal insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence without unnecessary words. It is concise and easy to parse, though the plural 'pairs' could have been more precisely 'pair' to match the pairId parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the description does not explain what the response contains, how pairId is formatted, or any limitations. Given the existence of sibling tools for searching pairs, this tool would benefit from specifying that it is for direct lookup of a specific pair, not discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already explains both parameters. The description adds the claim that chainId is optional and defaults to the active wallet chain, but this directly contradicts the schema, which lists chainId as required. This misleading addition undermines the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches pairs using chainId and pairId from Dexscreener. It distinguishes from sibling tools like dexscreener_search_pairs and dexscreener_get_token_pairs_by_token_address, though it does not explicitly name them. The plural 'pairs' with a singular pairId is slightly ambiguous but does not prevent understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as dexscreener_search_pairs. The description does not specify contexts, prerequisites, or exclusions, so the agent is left to infer usage from the name and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context ('with the wallet') but does not disclose important traits such as whether the signing is a standard personal_sign, requires user confirmation, or has security implications. The annotation openWorldHint is vague and does not convey the operational safety profile. No contradiction exists, but the description fails to enrich beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Sign', and contains no unnecessary words. It is perfectly concise and well-structured, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema), the description still lacks essential context: it does not state what the tool returns (e.g., a signature string) or mention any restrictions or chain-specific behavior. With no output schema, the description should explain the return value, which it does not. It also does not address usage context relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: chainId has a detailed description, but message has none. The tool description does not add any parameter semantics, leaving the message parameter underspecified. Since coverage is not high enough to rely on the schema alone, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sign') and the resource ('a message'), and specifies the context ('with the wallet'). It is a specific verb+resource pairing, but it does not distinguish from sibling signing tools like evm_sign_message or sign_typed_data_evm, which might also sign messages. Thus it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention prerequisites (e.g., active wallet) or exclusions (e.g., use sign_typed_data_evm for typed data). Without such context, the agent is left to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The openWorldHint annotation indicates a state-changing operation, which matches the transfer action. However, the description does not disclose important behavioral aspects such as whether approval is needed, the irreversibility of the transfer, or how chainId affects execution. The description adds little beyond what the annotation already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no superfluous words. It is front-loaded and directly states the operation, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a complete schema, the description fails to address contextual complexity: it does not mention chain selection, token approval prerequisites, decimal handling, or what the return value represents. Since this is an openWorldHint operation with many sibling tools, the description is too sparse for an agent to use it confidently in diverse scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a detailed description. The tool description adds no extra parameter semantics; it only repeats the general concept. Baseline of 3 is appropriate because the schema carries the explanatory weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (Transfer) and resource (an ERC20 token to an address), making the core purpose unambiguous. It does not explicitly differentiate from sibling tools like evm_transfer_erc20 or send_token, but the purpose is nevertheless clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many sibling tools that perform token transfers, the lack of any usage context or exclusionary language leaves the agent without sufficient information to select this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action ('approve') and does not disclose behavioral traits such as that it sends a transaction, requires gas, needs wallet approval, or returns a transaction hash. The annotation openWorldHint indicates external side effects, but the description adds no additional context about the mutation or signing process. For a state-changing tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the key action and objects. No unnecessary words. It earns its place without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool affecting the blockchain, the description provides only the basic action. It does not mention return values, transaction confirmation, errors, or any guidance on what happens after approval. With no output schema and minimal annotations, the agent gets little context beyond the schema fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all parameters (tokenAddress, spender, amount, chainId), so schema_description_coverage is 100%. The description itself adds no parameter semantics beyond what is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (approve), the object (an amount of an ERC20 token), and the target (an address). It is unambiguous and uses a specific verb. However, it does not distinguish this tool from sibling tools like evm_approve_token_spending or approve_token_evm, which likely perform the same operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many similar sibling tools. No prerequisites, preconditions, or alternatives are mentioned. The description simply states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose that this is an on-chain transaction that requires gas, wallet authorization, or has non-reversible effects (though approval can be revoked via another tool). The annotation 'openWorldHint: true' hints at external effects but does not clarify the transaction lifecycle, leaving the burden on the description, which remains shallow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It directly states the action and includes a useful parenthetical about units, earning its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transactional tool with no output schema, the description fails to mention important context such as the need for a connected wallet, network selection, or that it creates a transaction requiring confirmation. While the schema covers parameters, the description is too minimal to fully guide an agent in executing this state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all parameters with descriptions, and the description repeats the 'base units' detail without adding new meaning. Since coverage is 100%, the baseline is 3; the description adds no additional parameter insight beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Approve') and clearly identifies the resource (an ERC20 token) and the action parameters (amount in base units, spender). However, it does not distinguish this tool from sibling approval tools like 'evm_approve_token_spending' or 'approve', so it misses differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no contextual guidance on when to use this tool versus alternatives, such as 'evm_approve_token_spending' or 'get_token_allowance_evm'. It simply restates the function without mentioning any prerequisites, chain considerations, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the core action without disclosing any behavioral details such as how decimals are applied, return format, precision handling, or error conditions. The openWorldHint annotation provides minimal safety context and does not compensate for the lack of behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately communicates the core function. It contains no unnecessary words or redundancy, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and a very short description, the agent is left without information about the return value, conversion formula, or edge cases. The presence of similarly named siblings increases the risk of incorrect selection. The description does not sufficiently compensate for this lack of context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (amount, decimals, chainId), achieving 100% coverage. The tool description itself adds no additional parameter-level meaning beyond what the schema already conveys, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts an ERC20 token amount to its base unit, using a specific verb and resource. However, it does not distinguish itself from the sibling tool 'convert_to_base_units' (plural), which appears to have an identical purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the similarly named siblings 'convert_to_base_units', 'convert_from_base_unit', or alternatives. There is no mention of context, prerequisites, or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint:true and openWorldHint:true, but the description adds no behavioral context beyond the word 'reject'. It does not disclose irreversibility, state transitions, or any side effects, so the description contributes nothing beyond what the annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an exceptionally concise single sentence with no filler. However, it is so minimal that it borders on under-specification, sacrificing potential clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameters and the presence of annotations, the description is minimally adequate. It lacks details about the effects of rejection, required job state, or when rejection is appropriate, which would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with meaningful descriptions for all three parameters: jobId, reason, and chainId. The description itself adds no parameter details, but the schema is sufficient, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reject') and a clear resource ('ERC-8183 job'), making the action clear. It distinguishes from sibling tools like erc8183_complete_job or erc8183_submit_job by naming the rejection action, though it does not elaborate on what rejection entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the job needing to be submitted, nor does it contrast rejection with completing or claiming a refund. Usage is implied only by the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and openWorldHint, indicating a state-changing operation. The description adds no additional behavioral context—it does not disclose that submitting the deliverable hash is likely an irreversible on-chain transaction or mention any authorization requirements. No contradiction exists, but the description contributes nothing beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that immediately states the core action. It is front-loaded and contains no unnecessary words, exemplifying conciseness even if slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema, the description is minimal. It omits essential context: whether this involves an on-chain transaction, how it fits into the ERC-8183 lifecycle (after creation/funding, before completion), and potential side effects. The schema clarifies parameters but not the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every parameter described, including the key detail that the 'deliverable' string is keccak256 hashed. The tool description adds no extra parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (submit) and resource (job deliverable hash) within the ERC-8183 context, distinguishing it from siblings like erc8183_create_job or erc8183_complete_job. It lacks explicit detail about the hashing behavior but is specific enough for basic tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 in the ERC-8183 workflow. The description does not mention prerequisites (e.g., job creation, funding) or indicate that it should precede completion or rejection steps, leaving the agent to infer the sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the tool's name. The annotation 'openWorldHint: true' is present but the description does not elaborate on side effects, permissions, or whether the operation is read-only. No contradiction exists, but the description fails to explain any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. It earns its place without unnecessary words, though it may be too brief for a complete tool specification. It is well-structured for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what is returned. It only says 'Get the address' without specifying the return format (e.g., string, object) or context about which wallet address is returned (e.g., active wallet, chain-specific). This leaves significant ambiguity for an AI agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for its single parameter 'chainId', which is already documented. The description does not add any additional meaning to the parameter, so it provides no value beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the address of the wallet' clearly states the action (get) and the resource (address of the wallet), making the core purpose understandable. However, it does not specify which wallet (e.g., active wallet) or differentiate it from sibling tools like 'evm_get_wallet_address' or 'get_address_from_ens', so it lacks some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, any prerequisites, or context (e.g., active wallet vs. derived addresses). It simply states what the tool does without any instruction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint and do not declare readOnlyHint or destructiveHint. The description does not explicitly state that this is a read-only operation or mention any side effects, error conditions, or network dependencies, leaving the safety profile unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with a useful parenthetical example. It is front-loaded with the action and contains no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not describe the return value format or behavior for unregistered ENS names. It also ignores the chainId parameter and fails to clarify how this tool differs from similar sibling tools, leaving gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (chainId and ensName), so the schema carries the semantic load. The description adds only an example ENS name ('goat.eth') but does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the address') and resource ('ENS name') with a concrete example ('goat.eth'). However, sibling tools like evm_resolve_ens_name and evm_lookup_ens_address likely serve the same purpose, and the description does not differentiate between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as evm_resolve_ens_name or evm_lookup_ens_address. The description simply restates the function without contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Get the chain of the wallet' with no behavioral details. Annotation openWorldHint is vague and does not convey safety or side effects. No information is given about the return format or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, extremely concise with no wasted words. However, it may be too terse to convey necessary context, preventing a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter, the description is minimal but lacks any explanation of return values or behavior related to the chainId parameter. Without an output schema, the agent is left without essential information about what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the optional chainId parameter with a clear description. The tool description adds no additional parameter semantics, but schema coverage is high at 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with resource 'the chain of the wallet', clearly indicating it retrieves the wallet's chain. However, it does not differentiate from sibling tools like evm_get_chain_info or list_supported_chains, so not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are sibling tools such as evm_get_chain_info and list_supported_chains that could overlap, but no mention is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It does not disclose that this is a read-only operation, how the default chain is determined, or what the return value represents (e.g., raw integer vs. decimal). The openWorldHint annotation does not cover these details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify return format and behavior. It does not mention what the total supply value looks like, the default chain behavior, or provide any comparison to sibling tools, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (100% coverage), so the description is not required to add parameter semantics. It does not add any extra meaning, but the schema already handles this dimension effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the total supply of an ERC20 token, with a specific verb and resource. However, it does not differentiate from sibling tools like explorer_get_token_supply, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool over alternatives, nor does it mention the optional chainId parameter's role in selecting the network.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the core action and adds no behavioral context beyond the openWorldHint annotation. It does not disclose that this is a state-changing transaction, requires wallet ownership, or may incur gas costs. The implications of revoking an approval are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is efficiently written, though slightly awkward phrasing. It earns points for brevity but could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a blockchain write operation with no output schema, the description lacks critical context such as return values, chain behavior, and wallet requirements. The existence of sibling tools with similar functionality increases the need for additional clarity, but the description is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (100% coverage). The description itself adds no parameter-level detail, so it relies on the schema. This meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (revoke) and resource (ERC20 token approval) and indicates the target address. However, it does not differentiate from similarly named sibling tools like revoke_token_approval_evm, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the approval tools or the evm-specific variants. There is no mention of prerequisites, when this is appropriate, or alternative options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include 'openWorldHint: true', which is vague. The description adds that the tool can send both native and ERC20 tokens and emphasizes base units, but it omits critical behavioral details such as irreversibility, the need for wallet funds, transaction confirmation, or gas implications. For a state-changing operation like sending funds, this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('Send') and quickly specifies the resource and recipient. Every word is necessary, with no fluff or repetition. It earns a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sensitivity of transferring funds, the description is incomplete. It does not mention prerequisites (e.g., active wallet, sufficient balance), consequences (irreversible transaction), or how the optional chainId and tokenAddress parameters affect the operation. While the schema covers parameter syntax, the description lacks the necessary contextual warnings and usage constraints for a tool that moves value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, so each parameter is documented. The description's mention of 'base units' is already present in the schema's description of amountInBaseUnits, so it adds no new meaning. It does not clarify parameter relationships beyond what the schema already states, keeping the score at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Send native currency or an ERC20 token to a recipient, in base units.' It uses a specific verb ('send'), identifies the resource (native currency/ERC20), and mentions the recipient. However, it does not explicitly distinguish itself from sibling tools like 'transfer' or the EVM-specific transfer tools, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Given the presence of multiple transfer-related siblings (e.g., evm_transfer_native, evm_transfer_erc20, transfer), the description does not clarify whether this tool should be preferred for cross-chain operations or when both native and ERC20 sends are possible. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the openWorldHint annotation already signals. It does not disclose that this executes a blockchain transaction, requires signing/gas, or may have side effects like changing token balances on-chain. No additional traits are revealed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant information. It is appropriately sized for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having annotations, the description is minimal and omits critical context for a state-changing blockchain operation: no mention of wallet requirements, gas, execution mechanics, return values (no output schema), or how chainId affects behavior. This is insufficient for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters ('tokenAddress', 'from', 'to', 'amount', 'chainId'). The description itself adds no extra meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Transfer an amount of an ERC20 token') and the source/destination ('from an address to another address'). It is specific and unambiguous, but it does not distinguish from sibling tools like 'transfer' or 'evm_transfer_erc20' which likely perform similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention any prerequisites (e.g., wallet connection, gas requirements). It simply restates the function without contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true and openWorldHint=true, but the description adds no behavioral context beyond the verb 'create.' It fails to note potential on-chain side effects, requirements (e.g., funding), or irreversibility, thus adding no value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (five words) and front-loaded, but it is under-specified for a tool with six parameters and no output schema. While it wastes no words, it omits context that would make it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with multiple parameters and no output schema, the description is incomplete. It fails to explain the job lifecycle (e.g., funding, submission), expected return values, or side effects, forcing the agent to infer this from sibling tool names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description, so the baseline is 3. The tool description does not add any parameter semantics or relationships, providing no additional insight beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (create) and the resource (an ERC-8183 job). The ERC-8183 standard in the tool name distinguishes it from similar sibling tools like acp_create_job, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or how it differs from alternatives. The sibling list includes acp_create_job and other erc8183 tools, but the description does not mention them or indicate the appropriate context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation is openWorldHint: true, but the description does not clarify whether the conversion is a pure arithmetic operation or interacts with the blockchain. The chainId parameter hints at chain involvement, yet no explanation is given. No contradiction with annotations, but the tool's behavior is underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and easy to parse, making good use of the available space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and parameters are well-documented, there is no output schema and no explanation of the return value or the purpose of chainId. The openWorldHint annotation is not addressed, leaving some behavioral ambiguity. Adequate for a simple conversion, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all three parameters (amount, decimals, chainId), so the baseline is 3. The tool description adds no additional semantic detail beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Convert an amount of an ERC20 token from its base unit to its decimal unit' uses a specific verb and resource, clearly indicating a unit conversion. However, it does not differentiate itself from similarly named siblings like convert_from_base_units or convert_to_base_unit, so it loses 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its near-duplicate siblings (convert_from_base_units, convert_to_base_unit). No context about use cases, exclusions, or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description does not add behavioral context such as overwriting existing allowances, requiring gas, or submitting a transaction. Open-world hint is also not explained. The description merely restates the schema semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and structured, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive write tool with no output schema, the description is incomplete. It does not state what the tool returns (e.g., transaction hash) or what side effects occur, leaving the agent without critical operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully documented in the schema, so the description's mention of 'raw token units' is redundant. It does not add meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it approves an ERC-20 spender allowance, using a specific verb and resource. The phrase 'raw token units' distinguishes it from transfer tools and clarifies the amount format. This differentiates it from sibling tools like evm_transfer_erc20.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as approve_token_evm or evm_get_allowance. It does not mention prerequisites like wallet activation or checking current allowance, leaving the usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the openWorldHint annotation already implies. It does not mention return format, potential errors, or any side effects, and the annotation already covers the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is appropriately sized and front-loaded, delivering the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents all parameters and the optional chainId. However, with no output schema, the description could have clarified the return value (e.g., allowance amount), which it does not. Still, the combination of schema and description is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already self-explanatory in the schema. The description 'Get the allowance of an ERC20 token' adds no additional parameter meaning, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get the allowance') and resource ('ERC20 token'), with a specific verb and resource. However, it does not differentiate from sibling tools like evm_get_allowance or get_token_allowance_evm, which serve the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any context on prerequisites or exclusions. The description simply states what it does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's 'Create' action directly contradicts the annotation readOnlyHint=true, which signals a read-only operation. This is a serious inconsistency. The API key note adds some context, but the contradiction invalidates the behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no extraneous words. The API key note is a necessary prerequisite and is placed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple create operation with a rich schema, but there is no output schema and the description does not clarify what happens on success or failure. The API key prerequisite is helpful, but the annotation contradiction and lack of return-value info leave significant gaps for an agent invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions, achieving 100% schema_description_coverage. The description itself adds no parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create') and resource ('new offering on the aGDP marketplace'), making it clear what the tool does. It is distinct from the surrounding read-only market tools and from other agdp tools like agdp_get_offerings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'Create', and the API key prerequisite plus registration link provide useful context. However, there is no explicit guidance on when to use this tool versus alternatives, nor any when-not-to-use clauses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only openWorldHint in annotations, there is no clear safety or read-only indication. The description adds no behavioral details such as return format, sorting, pagination, rate limits, or limitations. It does not even explicitly state that the search is a read-only operation, leaving the agent to assume this from the verb 'search'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's purpose. There is no redundant text or filler, making it easy to parse and remember.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and only vague annotations, the description should at least hint at what the search results contain (e.g., pair addresses, token symbols, liquidity) or how to interpret the response. It does not, leaving a significant gap for a tool that will likely return lists of pairs with rich attributes. The description is adequate only for understanding the basic action, not the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (query and chainId), so the baseline is 3. The description adds no additional semantic clarity beyond mentioning 'query string', which aligns with the query parameter but does not explain nuances like wildcards or matching behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for DEX pairs using a query string on Dexscreener. It uses a specific verb (search) with a concrete resource (DEX pairs) and platform (Dexscreener), distinguishing it from sibling tools like dexscreener_get_pairs_by_chain_and_pair, which target specific lookup methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative dexscreener tools or other market search tools. It does not state any exclusions or prerequisites, relying entirely on the reader to infer usage context from the name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. However, the description adds no additional behavioral context—no mention of return format, pagination, timezone handling, or date inclusivity beyond what the schema already specifies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core operation. Every word contributes meaning without redundancy, making it appropriately concise for a straightforward data-retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having good parameter schema coverage and read-only annotations, the description lacks details about the return structure, date range inclusivity, timezone handling, or how daily counts are aggregated. With no output schema, the description should provide more context about expected results, so it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 4 parameters (chainId, startDate, endDate, sort), covering 100% of the parameters. The description adds no extra parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a clear resource ('daily transaction count') scoped to a date range. This distinguishes it from sibling tools like explorer_get_daily_gas_used or explorer_get_daily_new_addresses, which have different metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as explorer_get_tx_history or explorer_get_daily_gas_used. The description simply states the operation without indicating exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the behavioral detail that results are paginated, which is useful, but it does not disclose other aspects like rate limits, response format, or how pagination parameters interact. It does not contradict annotations, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly and efficiently conveys the tool's purpose. It is front-loaded with the verb and resource, contains no filler, and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and the tool has non-obvious distinctions from siblings (explorer_get_top_token_holders), the description is too sparse. It does not explain what the holder list contains (e.g., addresses, amounts), how to traverse multiple pages, or how page/pageSize behave in practice. This leaves the agent with insufficient guidance for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with descriptions (100% coverage), so the schema carries the semantic weight. The description text does not add any additional meaning beyond what is already in the schema, such as relationships or defaults, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (paginated list of token holders for a given token contract), making it easy to understand the core function. However, it does not distinguish itself from sibling tools like explorer_get_top_token_holders or research_token_holders, so it misses the top score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that this is for full holder lists as opposed to top holders, nor does it explain any pagination strategies or scenarios where this tool is preferred. The description simply states the operation without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint, which is not a behavioral/safety disclosure. The description adds no behavioral caveats such as chainId behavior, pagination, rate limits, response size, or result details. 'All DEX pairs' is the core behavior but lacks context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is appropriately sized for a simple read tool. Every word earns its place and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is sufficient for basic invocation, but with no output schema and sparse behavioral disclosure, the agent gets limited sense of return value shape or edge cases. It is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage with descriptions for both tokenAddresses (including maxItems: 30) and chainId (including default behavior). The description adds little beyond the 'all DEX pairs' framing and 'up to 30' constraint already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('all DEX pairs for given token addresses (up to 30) from Dexscreener'). It distinguishes this tool from sibling tools like dexscreener_search_pairs and dexscreener_get_pairs_by_chain_and_pair by specifying the token-address input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The phrase 'for given token addresses' only restates the input condition and does not mention exclusions, prerequisites, or when a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint true, so the description does not need to repeat that. However, it adds no further behavioral context such as whether the budget is overwritten, whether the job must already exist, or what the return value is. There is no contradiction with annotations, but the added value beyond them is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that states the action and key unit clarifier without any filler. It front-loads the primary purpose and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive mutation tool with no output schema and full parameter schema, the description is minimally viable. It explains what the tool does but omits lifecycle context, relationship to funding, and side effects. It is adequate for a simple setter but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are clearly documented. The description reinforces the amount unit ('smallest units'), matching the schema description, but does not add extra meaning about edge cases, inter-parameter dependencies, or chainId behavior. It meets the baseline for high schema coverage without further enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Set' and identifies the resource as 'ERC-8183 job budget' with units specified as 'payment token smallest units'. It is specific enough to distinguish from generic actions, but does not explicitly differentiate from closely related siblings like erc8183_fund_job, so it loses one point for lacking explicit contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 erc8183_fund_job or erc8183_create_job. It does not mention prerequisites (e.g., job existence), expected sequence in the job lifecycle, or any exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true and openWorldHint=true, which already indicate a safe read operation. The description adds the input scope (block number string or block hash) but does not disclose additional behavioral traits such as return format or whether transactions are included. Given the annotations, the description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded with the action and immediately specifies the accepted input types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential input format and indicates this is a read operation. However, with no output schema or explanation of return contents, the agent may not know what 'block details' includes (e.g., transactions, gas used). This is a moderate gap in an otherwise simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both chainId and blockIdentifier have descriptions in the schema. The description adds no additional semantic value beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get block details by block number string or block hash.' It specifies the resource and input type, making the purpose distinct. However, it does not explicitly differentiate from sibling tools like evm_get_latest_block or explorer_get_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of exclusions, prerequisites, or comparison with similar block-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds minimal context about chain scoping but doesn't explain behavioral nuances like how the latest block is determined or chain defaulting, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no superfluous words, effectively conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature and minimal schema, the description is minimally viable but vague about what 'block details' includes. With no output schema, the description could benefit from specifying return value content, though for a simple getter it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the optional chainId parameter with a clear description. The tool description adds no additional parameter information, so it relies on the schema to convey semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource 'latest block details for a chain', which conveys a distinct purpose. It is implicitly differentiated from sibling tools like evm_get_block that fetch specific blocks, but it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as evm_get_block or explorer_get_block. The usage context is only implied by the tool's name and description, with no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and external variability. The description adds the qualifier 'verified,' implying that unverified contracts will not have source, but it does not explain fallback behavior or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence ('Get verified source code for a smart contract.') that is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter structure and excellent schema coverage, the description is functional but lacks any note on what happens when source code is not verified or how to handle network-specific differences. It is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for both chainId and contractAddress. The description adds no additional parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'verified source code for a smart contract.' It is clear but does not explicitly distinguish from the sibling tool 'explorer_get_contract_code' which might return bytecode rather than source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this over explorer_get_contract_abi, explorer_get_contract_code, or evm_get_contract_abi. It only states the action without any context, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds no behavioral context beyond what the name and schema already convey. It does not disclose return format, aggregation details, pagination, or any limitations, and the phrase 'daily block rewards' merely restates the tool name with no additional behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence ('Get daily block rewards for a date range.') with no wasted words. It is front-loaded with the verb and resource, and every word contributes to the core purpose, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple schema, read-only annotations, and no output schema, the description is adequate for a basic query but lacks critical details such as the response structure, units of the rewards, or whether the data is aggregated per day or per block. While the input side is well-covered, the lack of any output/behavioral detail leaves the agent uncertain about returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for all four parameters (chainId, startDate, endDate, sort) with 100% coverage, so the description does not need to elaborate. The description only loosely mentions 'date range', which maps to startDate/endDate, but adds no extra meaning beyond the schema's built-in descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'daily block rewards' with a date-range scope, which provides a specific action and differentiates from the sibling tool explorer_get_block_rewards (which is not daily). However, it does not explicitly name an alternative or explain the aggregation semantics beyond the name, leaving slight ambiguity about what 'daily' means in the returned data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for date-range queries via 'for a date range' and the required startDate/endDate parameters, but it provides no explicit context on when to use this tool versus explorer_get_block_rewards or other explorer tools. There are no exclusion statements or named alternatives, so the guidance is only implicit from the phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation openWorldHint=true already signals a safe, likely read-only operation. The description adds minimal behavioral context beyond that, such as the notion of 'configured token' but no details on error behavior, required chain context, or what happens when the ticker isn't found. With annotations covering the safety profile, this is adequate but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly one sentence, front-loaded with the verb and resource, no filler or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description only gives partial return information ('like contract address and decimals') and doesn't explain what 'configured token' means or how the optional chainId affects the lookup. With no output schema, the description should carry more weight, so this is minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (ticker and chainId), so the schema already fully explains each parameter. The description adds no extra parameter context beyond restating that lookup is by ticker, which is already in the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets token information by ticker symbol, giving examples (contract address, decimals). However, it doesn't differentiate from the closely related sibling get_token_info_by_symbol, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_token_info_by_symbol or market_get_ticker. The description implies a 'configured token' context but doesn't explain when that context applies or when to choose this over other token lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds the behavioral detail of 'auto-resolving the pending memo and signing rejection', which gives some process insight. However, it does not disclose consequences like irreversibility, state changes, or authorization needs beyond what the annotation hints at, leaving the description to only partially supplement the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action and target. It contains no redundant words or filler, and every phrase adds meaning (e.g., 'auto-resolving' and 'signing rejection').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no output schema, yet the description does not explain what the tool returns on success, what side effects occur (e.g., job state changes, refunds), or any prerequisites like an active wallet or transaction confirmation. The description leaves significant gaps for safe use, especially given its destructive nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all three parameters (jobId, reason, chainId), each with a clear description. The tool description does not add any further semantic meaning or clarify parameter relationships, so it neither improves nor detracts from the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reject'), the target ('a job on the Virtuals ACPRouter'), and the mechanism ('auto-resolving the pending memo and signing rejection'). This distinguishes it from related ACP tools like acp_complete_job or acp_claim_refund.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, such as when to reject versus complete or claim refund, nor does it mention any prerequisites or context. The only usage signal is the tool name and the verb 'reject', which is insufficient for an agent to decide among sibling job lifecycle tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint and destructiveHint, so the agent knows this is a mutating open-world operation. The description adds minimal context (underlying function, optional token override) but does not explain side effects, permissions, or reverts. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the essential purpose without filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given destructiveHint=true and no output schema, more context is needed about return behavior, prerequisites (e.g., job existence, token approval), and consequences of overriding an existing budget. The description is too sparse for a mutating operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The description only echoes the 'optional token override' for paymentToken, adding little beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a job budget'), the target resource ('Virtuals ACPRouter'), and the specific underlying function ('setBudgetWithPaymentToken'). This distinguishes it from sibling tools like acp_fund_job or erc8183_set_budget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The mention of 'optional token override' hints at a default behavior, but there is no when-not or alternative tool referenced. Sibling erc8183_set_budget suggests a parallel standard, but this is not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The openWorldHint annotation is present, but the description doesn't contradict it and honestly describes a pure conversion operation without side effects. However, it doesn't disclose return format, precision/rounding behavior, or how token decimals are resolved beyond what the schema already states. With annotations lowering the bar, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with only 16 words, front-loading the key verb and outcome. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-operation nature, rich schema coverage, and lack of an output schema, the description sufficiently states the operation and target unit for an agent to select and invoke the tool. It could disambiguate from the near-duplicate singular sibling name, but this is a minor gap for such a straightforward conversion utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (amount, chainId, tokenAddress) are already well-documented. The description adds no extra parameter-level semantics beyond the overall conversion direction, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('convert') and identifies the resource ('token amount') and transformation direction ('human-readable units to its smallest unit (e.g., wei)'). This clearly states what the tool does, but it doesn't explicitly distinguish itself from the sibling tool convert_from_base_units or the singular convert_to_base_unit variants, so it stops short of 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the reverse operation (convert_from_base_units) or other conversion utilities. The context (schema and sibling names) implies it is for converting to base units before on-chain actions, but the description itself provides no explicit usage context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds the external dependency on Etherscan, which is useful context, but does not disclose potential failures such as unverified contracts or rate limits. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and scope. Every word contributes meaning, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with full schema coverage and annotations, the description adequately covers the core functionality. However, it lacks detail on return value format and failure modes, though these are partially implied by the tool name and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 chainId and contractAddress. The description adds no extra parameter meaning beyond the schema, which is acceptable per the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a contract ABI from Etherscan for a specific chain, using a specific verb and resource. However, it does not distinguish from the closely related sibling tool explorer_get_contract_abi, which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 explorer_get_contract_abi or evm_register_abi. The description neither mentions prerequisites nor exclusions, leaving the agent without decision 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=true, openWorldHint=true) already declare the safety profile, so the description does not need to repeat that. However, the description adds no extra behavioral context such as return format, error handling, or chainId semantics, offering minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that immediately conveys the tool's purpose without redundancy. It is front-loaded and every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with annotations and schema covering parameters, the description is sufficient. However, it does not specify the exact return payload or explicitly differentiate from similar transaction-related tools, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both txHash and chainId. The description does not add any additional meaning or usage details for the parameters, so it relies entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('transaction details') for a given hash. However, it does not explicitly distinguish from sibling tools like explorer_get_tx_details or evm_get_transaction_receipt, relying on the tool name for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as evm_get_transaction_receipt or explorer_get_tx_details. There is also no mention of the chainId default behavior or prerequisites, leaving the agent without decision-supporting context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful detail about the return content (status, logs, gas usage). However, it does not disclose potential edge cases like pending transactions or whether the receipt could be null, which limits transparency beyond the basic read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all essential information without redundancy. It wastes no words and is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description adequately covers its main function and key output fields. It lacks a note about the absence of an output schema and does not explicitly handle failure modes, but for a simple read-only receipt lookup, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for both parameters (txHash and chainId), covering 100% of parameters. The description's 'for a hash' merely reinforces the txHash parameter without adding new semantic meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the transaction receipt' for a hash, and enumerates key receipt contents (status, logs, gas usage). It does not explicitly differentiate from sibling tools like explorer_get_tx_receipt, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as explorer_get_tx_receipt or evm_get_transaction. It also lacks any mention of prerequisites or typical use cases, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds no additional behavioral details such as handling of invalid names, network dependencies, or return behavior beyond the bare definition of the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant information. It is appropriately front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one required parameter and no output schema, and the description adequately conveys the core function. However, it does not explicitly state the return value (the address) or edge-case behavior, and it lacks contrast with similar sibling tools, leaving some room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (ensName and chainId) with their types and descriptions, so the description adds no parameter-specific semantics. The schema coverage is 100%, satisfying the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Resolve' and the resource 'ENS name to EVM address', making the purpose unambiguous. However, it does not distinguish this from the similarly-named sibling evm_lookup_ens_address, which may cause selection ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like evm_lookup_ens_address or get_address_from_ens. The context is only implied by the action description, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the list of reward components (miner reward, uncle inclusion reward, uncle blocks) but does not disclose any additional behavioral traits such as pagination, return format, or rate limits. With annotations covering the basic safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the core function and key output details, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two required parameters and good schema coverage, the description is mostly complete. It names the specific reward fields, which is helpful. However, it lacks any usage context or mention of output structure, and there is no output schema to rely on. Still, given the simplicity of the tool, a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (chainId and blockNumber), so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. It lists output components but no details about parameter interpretation or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get block reward details including miner reward, uncle inclusion reward, and uncle blocks.' It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like explorer_get_daily_block_rewards or explorer_get_block, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of exclusions, prerequisites, or comparisons to similar explorer tools. The description only states what the tool does, not when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety is clear. The description adds minimal context about the output (collections and token IDs) but does not disclose pagination behavior, ordering, or potential limitations despite having page/pageSize parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core purpose efficiently, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with good schema coverage and annotations, the description is nearly sufficient. However, it omits any mention of return format or pagination behavior (e.g., default page size), which would be useful given the absence of an output schema. Still, the tool's simplicity and the rich schema keep it adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters (address, chainId, page, pageSize) described in the schema. The tool description does not add any parameter semantics beyond what the schema already documents, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List NFT collections and token IDs owned by an address' uses a specific verb and resource, clearly indicating the tool's scope. It does not explicitly name sibling tools like explorer_get_nft_transfers, but the 'owned by an address' phrasing distinguishes it from transfer-history tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as explorer_get_nft_transfers or evm_get_nft_info. The description simply states what it does without contextual or exclusionary hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true, which already define the safety and state characteristics. The description adds minimal behavioral context beyond noting the receipt includes status and gas usage, which is more about output content than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the primary action and immediately communicates what is returned. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While simple and adequately documented via parameters and annotations, the lack of an output schema means the description should ideally mention more about what a receipt includes. It mentions execution status and gas usage but omits other common receipt fields (logs, block number, etc.), leaving some ambiguity for agents expecting a complete receipt object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both txHash and chainId having clear descriptions. The description does not add extra meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a transaction receipt and highlights execution status and gas usage. It is specific about the resource and data focus, though it does not explicitly differentiate from sibling tools like explorer_get_tx_details or evm_get_transaction_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention typical use cases such as after submitting a transaction, nor does it reference sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'returns amount in base units', which is useful context beyond the openWorldHint annotation. However, the annotation is minimal and does not declare read-only status; the description implies a read operation but does not explicitly state that there are no side effects or disclose any limitations or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary purpose. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with no output schema, the description covers the purpose and return unit, while the schema covers parameters and defaults. It is slightly incomplete in not addressing sibling-tool differentiation or explicit chain behavior, but it is adequate for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters, so the description gets a baseline of 3. It adds the 'base units' detail, which helps interpret the result, but does not add further meaning beyond the schema's parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Get the allowance of an ERC20 token for a spender') and adds the return unit ('returns amount in base units'). This makes the purpose specific. However, it does not explicitly differentiate from similarly named siblings like get_token_allowance or evm_get_allowance, relying on the '_evm' suffix in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling tools such as evm_get_allowance or get_token_allowance. The description does not mention chain applicability, prerequisites, or alternatives, leaving the agent to infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the returned value is in base units and implies the need for conversion, which is valuable behavioral context beyond the openWorldHint annotation. It does not disclose other behavioral traits such as error handling, return type, or behavior with non-ERC20 tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with only two short sentences. The first sentence is clear and direct. The second sentence, while adding a useful note, is ambiguous (who performs the conversion?) and could be phrased more precisely, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, well-schema'd getter tool, the description is adequate but incomplete. It fails to differentiate from the nearly identical sibling evm_get_token_balance and does not explain the return type (e.g., string vs number) beyond units, leaving the caller to infer these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (wallet, chainId, tokenAddress), giving 100% coverage. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get the balance') and the resource (ERC20 token) with the unit (base units). However, it does not distinguish this tool from the similarly named sibling 'evm_get_token_balance', which appears to serve the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Convert to decimal units before returning' implies a post-processing step for the caller, providing some usage context. However, there is no explicit guidance on when to use this tool versus the many sibling balance tools, nor any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and openWorldHint=true, so the safety profile is partially disclosed. However, the description adds no additional behavioral context beyond the obvious action, such as prerequisites, irreversibility, or side effects. It does not disclose any meaningful behavioral traits beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. It contains no redundant words and effectively states the tool's purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two scalar parameters, no output schema, and annotations provide safety hints. However, the description omits important contextual cues such as when the refund can be claimed (e.g., after job completion) or what happens if no budget remains. Given the lack of output schema and the need for operational context, the description is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for both jobId and chainId. The description itself does not add extra meaning to the parameters, but since the schema already fully documents them, the baseline of 3 is appropriate. The description's reference to 'job' aligns with the jobId parameter but adds no additional detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Claim') and resource ('remaining budget for a Virtuals ACPRouter job'). It distinguishes from siblings like acp_get_job or acp_complete_job by focusing on the refund/claim action. Mentioning the underlying method 'claimBudget' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the context (claiming unspent budget from a job) but does not explicitly state when to use it versus alternatives like acp_get_job or acp_reject_job. There are no exclusions or alternative tool references. The usage scenario is implied, not directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint and openWorldHint, so the safety profile is known. The description adds the network (Base) but does not disclose that this is an on-chain transaction requiring wallet activation or that the job won't be active until funded via acp_fund_job.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the core action and lists the essential parameters. Every word contributes value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what and where, but it omits the surrounding workflow entirely. It doesn't mention that after creation, an agent might need to set a budget or fund the job, nor does it reference the output (e.g., job ID, transaction hash). Given the tool's moderate complexity and the existence of lifecycle-related siblings, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides comprehensive descriptions for all 7 parameters (100% coverage). The description simply restates four of the required parameters without adding extra meaning or clarifying the units or default behaviors already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a job on a specific router (Virtuals ACPRouter on Base) and lists the key parameters (provider, evaluator, description, expiry). This distinguishes it from siblings like acp_get_job or acp_set_budget, and even from erc8183_create_job by naming the ACPRouter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as acp_set_budget, acp_fund_job, or the ERC-8183 variants. The description does not explain the job lifecycle or how this creation step fits into the overall workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the `readOnlyHint: true` annotation, as 'Get' implies a read operation. It adds clarity about the owner-spender-token relationship but does not disclose return format (e.g., raw wei vs. decimal-adjusted), error behavior, or edge cases. With annotations covering safety, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant information. It front-loads the action and resource, fully occupying its purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what the return value represents, especially units (raw wei vs. token decimal adjustment). It also doesn't mention behavior for unapproved allowances (returns 0) or invalid contracts. While the core purpose and parameters are clear, the missing return semantics leave a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptive schema entries, so the schema carries the parameter documentation burden. The description's phrase 'from owner to spender for a token contract' mirrors the schema's ownerAddress, spenderAddress, and tokenAddress fields but adds no new format, type, or default information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Get'), a specific resource type (ERC-20 allowance), and the key participants (owner, spender, token contract). It is distinct from sibling tools that handle balances, transfers, or approvals, and it accurately conveys the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like `evm_get_token_balance` or `get_token_allowance_evm`, nor does it suggest checking allowance before an approve/transfer action. There is no explicit or implied context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds the detail that the tool returns the latest block number. No contradiction exists, but the description does not disclose the full return structure or any other behavioral nuances beyond what the schema and annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the tool's purpose without any redundant words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one optional parameter and no output schema. The description mentions the latest block number as a key return value but remains vague about what 'basic chain status' includes. Without an output schema, a bit more detail about the return value would improve completeness, but it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the chainId property includes its own description ('Chain ID (defaults to runtime config)'). The description merely repeats 'chain ID' and does not add additional semantic meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves basic chain status including the latest block number for a given chain ID, using a specific verb and resource. It is distinguishable from siblings that focus on individual blocks or transactions, though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to fetch chain-level status, but it does not explicitly state when to prefer it over related tools like evm_get_latest_block or evm_get_block, nor does it provide any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond the readOnlyHint and openWorldHint annotations. It does not mention return format, default chainId behavior, or edge cases, leaving the agent without additional context about the operation's outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's function without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the core purpose, but the absence of an output schema means the description should clarify the return value (e.g., string vs number). It also doesn't mention the default behavior of chainId, despite that being in the schema. Overall adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all four parameters (chainId, tokenId, ownerAddress, tokenAddress), and the description does not add extra meaning. Baseline of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'ERC-1155 token balance' with required parameters 'owner and token ID', clearly distinguishing it from generic balance tools like evm_get_balance and evm_get_token_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ERC-1155 tokens but does not explicitly contrast with alternatives like evm_get_token_balance or provide when-not-to-use guidance. It relies on the tool name and description to convey context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, so the description adds no extra behavioral context. The phrase 'daily average gas used' is ambiguous about whether the result is a single averaged value or a per-day series. No return format or timezone behavior is disclosed, leaving the agent uncertain about output semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. No wasted words or redundant restatements of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only metric tool, the description is minimally sufficient but lacks important context: there is no output schema, so the response shape is undocumented, and no usage alternatives are noted. The annotations provide safety, but the description does not clarify the exact data returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented with meaningful descriptions. The tool description adds no additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('daily average gas used') and scope ('for a date range'). This distinguishes it from sibling explorer tools like explorer_get_daily_tx_count or explorer_get_daily_new_addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when daily gas usage data is needed, but it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or prerequisites beyond the schema. No sibling differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds no further behavioral context, such as timezone handling, pagination, or what 'new addresses' means. It is consistent with annotations but does not add significant value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that fully states the purpose. No wasted words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameters, but there is no output schema. The description does not specify the return format or whether it returns a list, a map, or an aggregate. Given the name and phrasing, the return type is somewhat implied but not explicit, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema (100% coverage), so the schema carries the full weight. The tool description does not add any additional meaning beyond what is already in the schema, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('daily new address count'), and the scope ('for a date range'). It distinguishes this from sibling tools like daily_tx_count or daily_gas_used because 'new address count' is a specific metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no mention of when to use this tool versus alternatives, nor any exclusions. The description simply states what it does, leaving the agent to infer from the name and sibling context. No explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that internal txs include contract-to-contract calls, which is useful context. However, it doesn't disclose potential limitations like block range filtering, pagination behavior, or what types of traces are included/excluded beyond the one example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the primary purpose and includes a clarifying detail without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys what the tool does but omits information about the return format or pagination. Since there is no output schema, the description should provide more context about what the results look like. It is sufficient for a simple read operation but lacks completeness for a 6-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema (100% coverage), so the description doesn't add semantic value beyond what the schema provides. The description's mention of 'for an address' aligns with the 'address' parameter but doesn't explain the other parameters or their defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets internal (trace) transactions for an address, with a specific verb and resource. The added detail 'including contract-to-contract calls' differentiates it from other explorer transaction tools like explorer_get_tx_history or explorer_get_token_transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention comparison to sibling tools, prerequisites, or scenarios where another tool would be more appropriate. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which cover the safety profile. The description adds minimal context by specifying 'pending' but does not disclose behaviors like polling limits or return formats, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the purpose without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations, the description is adequate but lacks mention of the return value format or the polling behavior implied by maxAttempts. Since there is no output schema, this missing information could leave the agent uncertain about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all four parameters (100% coverage), so the tool description does not need to add parameter details. It also doesn't add any extra meaning beyond what the schema already explains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('the status of a pending Orbs Liquidity Hub swap'). It effectively distinguishes this from sibling tools like orbs_swap and orbs_submit_signed_swap by focusing on status verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites (e.g., having submitted a swap first) or contrast with related tools like orbs_query_orders, leaving the agent to infer the proper usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the primary side effect—setting allowance to 0—which is essential behavioral context. However, it does not mention that this is an on-chain transaction requiring gas, wallet confirmation, or that it permanently alters state. With only 'openWorldHint: true' as annotation, the description adds some value but leaves the full side-effect profile implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and includes a clarifying parenthetical. Every word earns its place with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and effect, and the schema fully documents inputs. However, it does not mention return values (e.g., transaction hash), network side effects, or execution context. For a relatively simple tool with full param documentation, this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all three parameters (chainId, spender, tokenAddress) at 100% coverage. The tool description does not add any additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Revoke' and names the resource 'approval for an ERC20 token from a spender', explicitly stating the effect: '(sets allowance to 0)'. This clearly differentiates it from approve-family tools and other token operations, despite not explicitly mentioning EVM (the name carries that context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'approve_token_evm', 'approve', or 'revoke_approval'. There are no prerequisites, exclusions, or context about when to prefer this tool, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read-only nature is known. The description adds useful detail about what is returned (base gas price and priority fee estimates) but does not disclose additional behavioral traits such as default chain behavior, response shape, or error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the main purpose and contains zero filler. It efficiently conveys the tool's action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description adequately explains what will be returned. The default chainId behavior is covered by the schema. It could be slightly more complete by mentioning the default chain explicitly in the description, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one optional chainId parameter clearly described as 'Chain ID (defaults to runtime config)'. The description adds no additional parameter semantics, but the schema fully documents the parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource: current base gas price and priority fee estimates for a chain. It is distinct from sibling tools like evm_get_balance or market_get_funding_rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no exclusions, and no context about choosing chain IDs or when this data would be relevant. It is a bare statement of function without usage framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and open-world aspects. The description adds no further behavioral details such as return format when no ENS name exists or any error conditions. Since it does not contradict annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is well-structured and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with complete schema and annotations, the description adequately conveys the tool's purpose and implicitly defines the return value (ENS name). It could explicitly state output, but the name and 'reverse' phrase make this clear enough for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (address and chainId) documented in the schema. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform reverse ENS lookup for an address' clearly states the specific action (reverse lookup) and resource (ENS). It explicitly distinguishes from forward resolution tools like evm_resolve_ens_name by using 'reverse', leaving no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that forward ENS resolution would require a different tool, nor does it describe any prerequisites or edge cases (e.g., addresses without ENS records).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds value by breaking down the supply components ('staking, burned fees, withdrawal totals'), but it doesn't disclose other behavioral traits like return format, units, or pagination. With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description is reasonably complete: it states purpose, scope, and key components of the response. It lacks a note on units or return type, but is not severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for chainId, and the description provides no additional parameter semantics. Per the baseline rule for high schema coverage, this scores 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('native token supply'), and further specifies components (staking, burned fees, withdrawal totals). This clearly distinguishes it from sibling tools like explorer_get_token_supply for non-native tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., explorer_get_token_supply for ERC-20 supplies, or explorer_get_native_price for price). It doesn't mention chain requirements or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that results are sorted by balance and limited to top N, which are useful behavioral traits. However, it does not disclose other behaviors like default count, ordering direction, or pagination, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It efficiently communicates the core action without redundancy, earning the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with clear annotations and fully described parameters, the description is largely complete. It lacks a brief note on the expected return format (e.g., list of addresses and balances) and does not differentiate from the similar explorer_get_token_holders, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters (count, chainId, contractAddress). The description adds minimal semantic value beyond echoing 'top N' for count and 'token contract' for contractAddress, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the top N token holders by balance for a given token contract.' It specifies the resource (token holders), the operation (get), and the scope (top N by balance), which distinguishes it from sibling tools like explorer_get_token_holders or research_token_holders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of using it for quick top-holder lookups, nor any exclusions like 'for full holder lists, use explorer_get_token_holders.' The description does not differentiate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds context about the included data (decoded input parameters and token movements), but it does not disclose any additional behavioral traits such as rate limits, pagination, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without redundancy. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool signature (two parameters, no output schema) and strong annotations, the description adequately communicates what the tool returns. However, it lacks any note on how this differs from related explorer tools, and it doesn't mention any limitations or network-specific behavior, so it is not a perfect 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters with descriptions (txHash format and chainId required). The description adds no additional parameter semantics beyond what is already in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and specifies the resource 'full transaction details' with concrete inclusions (decoded input parameters and token movements). This clearly distinguishes it from sibling tools like explorer_get_tx_receipt or explorer_get_tx_history, which focus on receipt or history only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any exclusions or point to sibling tools for other cases, leaving the agent to infer usage solely from the tool's name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety expectations. The description adds the ability to filter by block range but does not disclose pagination behavior, result ordering, or any rate limits. Given the annotations, the description meets a baseline but adds limited beyond-annotation value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core function ('Get transaction history for an address') and mentions optional filters. It is concise with no wasted words, achieving high structural efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no output schema, so the description needs to cover return format and pagination but does not. The spurious 'method' reference adds confusion. However, the rich schema and annotations (read-only, open-world) make it minimally complete for a filtered list tool, though not contextually rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all six parameters have descriptions), which would normally warrant a baseline of 3. However, the description mentions a 'method' filter that does not exist in the schema (only startBlock/endBlock are present). This mismatch could mislead the agent into looking for a non-existent parameter, reducing the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get transaction history for an address' with a specific verb and resource. It implicitly distinguishes from sibling tools like explorer_get_tx_details (single transaction) and explorer_get_token_transfers (token-specific) by focusing on full transaction history, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving address transaction history but does not explicitly state when to use it vs. alternatives such as explorer_get_tx_details or explorer_get_internal_txs. No exclusions or alternative names are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the agent knows this is a mutation. The description adds that the job advances to evaluation phase, but does not disclose irreversibility, required permissions, or side effects beyond the phase change. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action verb 'Submit' and contains no fluff. It conveys the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple mutation tool given the annotations and 3-parameter schema, but it does not explain prerequisites (e.g., job state), return value, or failure modes. With no output schema, the agent might need more context about what happens after submission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all parameters (100% coverage), so the baseline is 3. The tool description adds the context that deliverable is a 'memo', slightly clarifying its purpose, but otherwise does not enrich the parameter meanings beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Submit' and names the resource 'deliverable memo on the Virtuals ACPRouter' plus the outcome 'advance the job to evaluation phase.' This clearly differentiates from sibling tools like acp_complete_job or acp_reject_job by indicating the submit action and phase transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a job exists and a deliverable must be submitted, but it does not explicitly state when to use it versus alternatives like acp_complete_job or acp_reject_job. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and open-world, but the description adds the crucial requirement of 'wallet + confirmation required,' which is not captured by annotations. This informs the agent that the operation will trigger a blockchain transaction requiring user approval, adding value beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and requirements, with no wasted words. It efficiently conveys the core purpose and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema, but the schema descriptions fill in parameter meanings. The description omits what the tool returns or how the update is executed (e.g., IPFS auto-pinning vs pre-hosted URI), which could be useful, but given the schema coverage it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 7 parameters with detailed descriptions, so the schema already provides meaning for each field. The description does not add parameter-level insight beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' and names the resource 'ERC-8004 agent metadata URI', which distinguishes it from siblings like erc8004_register_agent. However, it focuses on 'URI' while the schema allows updating multiple metadata fields (name, services, etc.), making the description slightly narrower than the actual functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for updating an existing ERC-8004 agent rather than registering a new one, but it does not explicitly state when to use it over alternatives. It provides context that it is a write operation requiring wallet and confirmation, indicating it should be used when an existing agent's metadata needs modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and openWorldHint, indicating this is a potentially destructive operation. The description adds the specific consequence 'release escrow', which is useful context beyond the annotations. However, it does not disclose irreversibility, state requirements, or return behavior, so the additional transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb 'Complete' and the resource, with no redundant or filler content. It immediately conveys the core purpose and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, the annotations provide safety context (destructiveHint), and the schema is fully documented. The description covers the core action and immediate effect ('release escrow'). However, it lacks information about when the job can be completed (e.g., required prior states), which might be important for correct invocation, making it minimally sufficient rather than thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all parameters (jobId, reason, chainId) with clear descriptions. The tool description does not add any parameter-specific semantics beyond what the schema already contains, so it neither enhances nor detracts from the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Complete') and the resource ('an ERC-8183 job'), with a specific outcome ('release escrow'). It distinguishes from sibling tools like erc8183_submit_job and erc8183_reject_job by using 'complete' as the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action of 'complete' implies it is used to finalize a job after it has been submitted, but the description does not explicitly state when to use it versus alternatives like erc8183_submit_job or erc8183_reject_job. No exclusions or prerequisites are mentioned, leaving usage context partly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and variability. The description adds that it returns a block number, which is useful, but it does not disclose potential edge cases, precision details, or behavior when timestamps fall outside chain range. Meets the baseline with annotations but no extra depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that front-loads the core purpose and includes the key 'before or after' qualifier. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter lookup tool with no output schema, the description gives the essential purpose and return type (block number). However, it does not specify the exact return format or handle edge cases like timestamp outside chain history. It is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, and the description adds minimal value by restating the 'before or after' behavior and the output is a block number. It does not provide syntax examples or clarify edge cases beyond schema. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds the block number closest to a given Unix timestamp, with the 'before or after' option. This is a specific verb-resource combination and distinguishes it from siblings like explorer_get_block which likely fetches by block number or hash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need a block near a timestamp), but it does not explicitly mention alternatives or exclusion scenarios. It lacks the explicit 'use X instead' guidance seen in higher-scoring examples. The usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds minimal behavioral context beyond the 'no address required' constraint; it does not disclose potential performance implications of scanning all contracts or return limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that contains the key information: action, scope, filters, and a distinguishing caveat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description does not explain return values or result size. It is adequate for a basic read operation with annotations, but misses potential caveats like large result sets or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter details are already documented. The description mentions topics and block range but adds no additional formatting or syntax guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving event logs across all contracts using topic and block range filters, explicitly noting that no address is required. This distinguishes it from the sibling explorer_get_event_logs, which likely requires an address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (filter by topics and block range across all contracts) but does not explicitly name alternatives or give when-not-to-use guidance. It implies usage scenarios but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, so the description does not need to restate that. It adds meaningful context by noting the order is 'confirmation-gated' and 'executes only when output meets minimum amount', revealing conditional execution behavior not captured elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, and front-loaded with the core purpose. Every word contributes to understanding, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema and annotations cover parameters and safety, the description lacks information about return values (e.g., order ID) and the confirmation flow. Given the tool's complexity and the existence of preparation/intent siblings, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 8 parameters (100% coverage), so the description does not need to explain parameter meanings. It adds no extra parameter semantics beyond what the schema already gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places a limit order via the Spot protocol, which is specific and action-oriented. It differentiates from swap/TWAP tools by mentioning 'limit order' and 'Spot protocol', but does not explicitly distinguish from the sibling 'orbs_place_order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for limit orders and mentions the execution condition, but gives no explicit guidance on when to choose this over alternatives like orbs_place_order or orbs_prepare_limit_intent. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read operation. The description adds value by explaining that the tool summarizes configured authenticated vs. public access and market-type metadata, which clarifies the output shape beyond the annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence. It front-loads the primary action ('List CCXT-supported exchanges') and then succinctly lists the summary aspects. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description conveys the main output type: a summary of exchanges with their auth/access status and market-type metadata. It lacks explicit return formatting or examples, but given the tool's simplicity and strong schema/annotations, it is reasonably complete. Minor ambiguity about whether the output is a filtered list or an all-encompassing summary prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not directly elaborate on parameter behavior beyond what the schema already provides, such as the hasAuth filter or marketType enum. It only vaguely references 'market-type metadata' which aligns with marketType but adds no new detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'List' and the resource 'CCXT-supported exchanges', then specifies the summary dimensions (authenticated accounts, public market access, market-type metadata). This distinguishes it from sibling tools like ccxt_list_accounts (accounts only) and ccxt_describe_exchange (single exchange details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The description implies discovery of exchanges and their capabilities, but does not mention ccxt_describe_exchange for per-exchange details or ccxt_list_accounts for account-level info. There is no 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint=true, and the description does not add significant behavioral context beyond that. It does not mention return format, rounding behavior, or how token decimals are resolved, though the schema partially covers this. No contradictions, but limited added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion tool with full schema coverage and an openWorldHint annotation, the description is largely complete. It clearly defines the input-output relationship, though it does not explicitly state the return type; however, this is implied by 'human-readable units'. The absence of an output schema is mitigated by the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented. The description adds minimal extra meaning beyond the schema, only clarifying the output is 'human-readable units'. This meets the baseline but does not go beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a token amount from its smallest unit (e.g., wei) to human-readable units, which is a specific verb+resource and distinguishes it from convert_to_base_units siblings. The direction is unambiguous and matches the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have a base-unit amount and want a human-readable equivalent) but does not explicitly state when to use it versus convert_to_base_units, nor does it mention exclusions or prerequisites. The context is clear but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds that it returns an 'aggregate' summary and allows 'optional tag filters', which is useful but not deeply behavioral. It does not disclose return format, default behavior without tags, or how tag filtering combines (AND/OR). Given annotation coverage, a score of 3 credits the minimal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary purpose ('Get aggregate ERC-8004 reputation summary') and follows with the optional qualifier ('for an agent with optional tag filters'). No wasted words, clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple query tool with four parameters, a full schema, and readOnly/openWorld annotations. The description, combined with the schema and annotations, provides sufficient context for an agent to decide when to invoke it and what to expect (an aggregate summary). A small gap is that no output schema exists, so the description could clarify what 'summary' contains, but given the low complexity and annotation coverage, the overall context is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: all four parameters have descriptions (agentId as 'Agent token ID', tag1/tag2 as 'Filter by tag N', chainId as 'Target chain ID (default from runtime config)'). The description's mention of 'optional tag filters' merely confirms the schema. It adds no new meaning beyond the schema, so the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get aggregate ERC-8004 reputation summary for an agent with optional tag filters.' It uses a specific verb ('Get'), names the resource ('aggregate ERC-8004 reputation summary'), and adds scope ('for an agent with optional tag filters'). This distinguishes it from sibling tools like erc8004_get_agent, which likely returns individual agent details, and erc8004_submit_feedback, which writes feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need an aggregate reputation summary with optional tag filtering, use this tool. However, it does not explicitly list when to use it versus alternatives, nor does it mention exclusions or provide guidance on how it differs from erc8004_get_agent. The usage context is only implied by the wording, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description doesn't need to repeat them. It adds value by listing the specific fields returned (collection metadata, owner, tokenURI), but it does not disclose additional behavioral traits such as error behavior or external data fetching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence of 11 words, front-loaded with the verb and resource. It contains zero redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with good annotations and complete schema, the description is sufficient. It covers the core purpose and return content. However, without an output schema, a bit more detail on the exact response structure could be helpful, but it is not necessary given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for all three parameters (tokenAddress, tokenId, chainId). The description adds no extra parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets ERC-721 NFT details including collection metadata, owner, and tokenURI. This is a specific verb + resource that distinguishes it from sibling tools like explorer_get_nft_inventory or explorer_get_nft_transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying a specific NFT by contract address and token ID, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide openWorldHint and destructiveHint, so the safety profile is known. The description adds the 'active wallet' scoping, which is useful context, but it does not disclose other behavioral traits such as whether a signature is returned, whether any transaction is broadcast, or if any side effects occur beyond signing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. Every word earns its place, and the key qualifier 'arbitrary UTF-8' is placed immediately to clarify the message scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is largely sufficient. It covers the signing intent and active-wallet context. It could mention the output (a signature) or call out that no transaction is broadcast, but given the tool's simplicity and the annotations, the slight omission is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'message' parameter, providing the baseline. The description's phrase 'arbitrary UTF-8 message' adds meaningful semantics about accepted formats (any string encoded as UTF-8) that go beyond the schema's terse 'Message to sign'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sign'), the resource ('arbitrary UTF-8 message'), and the context ('with the active wallet'). This distinguishes it from sibling tools like evm_sign_typed_data (which signs typed structured data) and sign_message (generic, not EVM-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that evm_sign_typed_data should be used for typed data, nor does it clarify any prerequisites like wallet activation. The usage context is only implied by the tool name and the phrase 'active wallet'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and openWorldHint=true, covering the safety profile. The description adds context about the active wallet and typed data, but it does not disclose whether the signing is off-chain, whether confirmation is required, or what the returned signature format is. It provides minimal extra behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant words. It efficiently conveys the essential purpose without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should at least hint at the return value (e.g., the signature). It also lacks mention of prerequisites like wallet activation or potential errors from malformed JSON. For a signing tool that has destructive implications, the description is too sparse to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters have descriptions in the schema. The tool description adds no additional parameter-level detail beyond the general mention of 'EIP-712 typed data payload', which is already implied by the schema. Baseline of 3 is appropriate since the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Sign'), a precise resource ('EIP-712 typed data payload'), and the actor ('active wallet'). It clearly differentiates from sibling signing tools like evm_sign_message by specifying the typed data format, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for signing EIP-712 typed data, implying it should be used for structured data rather than simple messages. However, it does not explicitly state when not to use it or name alternatives, though sibling differentiation is implicitly clear from the 'EIP-712' qualifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and open-world. The description adds the nuance of supporting ENS names, but it does not disclose additional behavioral details such as the need for gas, wallet activation, or transaction confirmation behavior beyond the obvious transfer semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and resource, and no unnecessary words. It is appropriately minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with full schema coverage and destructive annotation, the description is sufficient. It could mention the return value or prerequisites, but those are not essential given the annotations and simplicity. Sibling tools provide additional context on related operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline score of 3 applies. The description mentions 'address or ENS name' and 'native tokens' but adds no new param detail beyond what the schema already provides for 'to', 'amount', and 'chainId'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (send), resource (native tokens), and target (address or ENS name). It distinguishes from sibling evm_transfer_erc20 by explicitly limiting to native tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'native tokens' but does not explicitly mention when to use this tool over alternatives like evm_transfer_erc20 or when not to use it. No explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which covers safety and scope. The description adds the response content (balances, ENS, contract metadata, tags) but no further behavioral traits like data freshness, indexing delays, or rate limits. It is consistent with annotations but provides only modest additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler: 'Get address overview including balances, ENS name, contract metadata, and public tags.' It is front-loaded with the verb and resource, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description enumerates the key return categories, which is sufficient for a read-only overview tool with two well-documented parameters. Minor gap: it doesn't note that fields like ENS name may be absent for addresses without ENS, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'address' and 'chainId' have clear descriptions in the input schema. The description does not add new parameter semantics beyond what the schema already states, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource 'address overview' and enumerates distinct content categories (balances, ENS name, contract metadata, public tags). This clearly distinguishes it from sibling tools like explorer_get_tokens_by_address or explorer_get_tx_history, which focus on narrower aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for general address overviews but provides no explicit when-to-use, when-not-to-use, or alternative tool guidance. It does not contrast with more specific explorer tools, so the agent must infer usage from the content list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description only needs to add context. It does mention the return contents (gas consumption, rewards, optional tx list) but does not disclose additional behaviors like pagination, response size, or cost. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly written sentence that front-loads the action and resource, then efficiently lists the key data points. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-described parameters and no output schema, the description adequately conveys what the tool returns. It does not mention the option to request the full transaction list (e.g., via a parameter), but overall it is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (chainId, blockNumber) have clear descriptions. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('block information') and enumerates specific contents (gas consumption, rewards, optionally full transaction list), which clearly distinguishes it from sibling tools like explorer_get_block_rewards (rewards only) and evm_get_block (generic block data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the description: use when you need block-level data with gas/rewards and optionally transactions. However, there is no explicit guidance on when to choose this over alternatives (e.g., explorer_get_block_by_timestamp, evm_get_block), nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description need not restate safety. It adds the behavioral context of 'mined/validated' but does not disclose pagination behavior, return format, or any caveats about data availability. With annotations covering the read-only nature, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the essential purpose in minimal words, earning every bit of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (pagination, required chainId), the description is reasonably complete. It doesn't explicitly mention return structure or pagination behavior, but since there is no output schema and the input schema documents pagination, the description covers the core functionality. It could be improved by noting that results are paginated or that chainId determines network, but the overall context is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions (address, chainId, page, pageSize). The description's phrase 'by a specific address' maps to the address parameter but adds no new semantic meaning beyond the schema, which already explains each parameter's purpose and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource ('blocks mined/validated by a specific address'). It clearly differentiates from sibling tools like explorer_get_block (by block number) and explorer_get_block_by_timestamp (by timestamp) by focusing on validator address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when querying blocks associated with a validator address, but it does not explicitly state when to prefer this over other explorer tools or provide exclusion criteria (e.g., 'use instead of explorer_get_block when you have an address rather than a block number'). The usage context is inferred but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, and the description adds a meaningful behavioral constraint: only source-verified contracts are supported. It does not disclose error behavior or return format, but for a simple read-only tool with strong annotations this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the key action front-loaded. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with complete schema coverage and informative annotations, the description provides sufficient context. The absence of an output schema is mitigated by the fact that 'Fetch the ABI' makes the return type obvious, though a brief mention of error behavior would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters (chainId, contractAddress) are already well-described in the input schema. The description adds no additional parameter-level detail, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Fetch the ABI', giving a specific verb and resource, and narrows the scope to verified smart contracts. The 'source-verified' restriction helps distinguish it from siblings like evm_get_contract_abi or evm_register_abi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear condition: it works only for source-verified contracts. However, it does not explicitly mention when to prefer this over sibling tools such as evm_get_contract_abi or evm_register_abi, leaving the differentiation implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the safety and scope profile. The description adds no further behavioral context such as return format, potential errors, or prerequisites. It doesn't contradict the annotations, but it also doesn't enrich them 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the verb and resource. Every word adds value, with no redundancy or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, full schema coverage, and clear annotations, the description is nearly complete. It could arguably mention the return format (hex-encoded bytecode) since no output schema is present, but the term 'deployed bytecode' strongly implies this. No critical information is missing for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the input schema. The description only references 'at a given address' without adding new semantic details about the chainId or address format beyond what the schema provides. The baseline of 3 applies when the schema carries the explanatory burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get') on a specific resource ('deployed bytecode of a contract') with a location parameter ('at a given address'). It clearly distinguishes itself from sibling tools like explorer_get_contract_abi or explorer_get_contract_source, which retrieve different contract data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving contract bytecode but provides no explicit guidance on when to choose this tool over alternatives. No exclusions or alternative comparisons are mentioned, leaving the agent to infer based on the tool name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not responsible for conveying safety. It adds the return values (deployer and creation transaction hash), which is useful. However, it does not disclose any additional behavioral traits such as edge cases for contract creations via internal transactions or potential null results, though the annotations lower the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (11 words) that immediately states the tool's purpose. It is front-loaded with the action and the result, with no filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query with two well-documented parameters, the description adequately covers what the tool does and what it returns. It does not explain return format or edge cases, but the absence of an output schema and the tool's simplicity make this acceptable. It could have mentioned potential null cases or the meaning of openWorldHint, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains both parameters (chainId and contractAddress). The description adds no parameter-specific semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and clearly identifies the resource: the contract deployer and the creation transaction hash. It distinguishes this tool from sibling explorer tools like explorer_get_contract_abi or explorer_get_contract_source, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to identify who deployed a contract and the deployment transaction. However, it does not explicitly mention when not to use it or point to alternatives, unlike the best examples that name a specific sibling tool. The context is clear but not expanded with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that the output is 'daily' and a 'percentage', but does not disclose additional behavioral details like data freshness, timezone handling, or response format. This is acceptable given the annotations but offers only minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant information. It efficiently states the action, the data granularity, and the date-range scope, making it easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only metric tool with fully documented parameters and annotations, the description sufficiently conveys the core function and expected output granularity. It lacks details about return structure or precise definition of 'network utilization', but given no output schema and the simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for 100% of the parameters, so the baseline is 3. The description does not add any parameter-level detail beyond what is already in the schema, such as date format examples or clarification of the 'sort' parameter. Meaning is fully captured by schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' along with the resource 'daily network utilization percentage' and a clear scope 'for a date range'. This clearly distinguishes it from sibling tools like explorer_get_daily_tx_count or explorer_get_daily_gas_used, which target different metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when network utilization data is needed, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. No guidance is given beyond the core function, so it lacks explicit usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations readOnlyHint=true and openWorldHint=true, the safety profile is already clear. The description adds value by specifying the return fields (name, symbol, decimals, total supply, social profiles), which goes beyond the schema's parameter descriptions. It does not discuss error handling or data sources, but for a read-only metadata tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get token metadata including name, symbol, decimals, total supply, and social profiles.' Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description adequately conveys the tool's purpose and return contents. It is complete enough given the schema and annotations, though it could optionally mention that the tool operates on a specific chain and contract address to further differentiate from ticker-based token info tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: chainId is described as 'Chain ID for the target network (required — no default for indexed data)' and contractAddress as 'Contract address (0x-prefixed)'. The description adds no additional parameter semantics, but the schema already fully documents both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get token metadata including name, symbol, decimals, total supply, and social profiles.' This uses a specific verb ('Get') and resource ('token metadata'), and the list of fields distinguishes it from siblings like explorer_get_token_supply (which only returns supply) and explorer_get_token_holders (which returns holders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 that this is suitable for fetching comprehensive metadata by chain/address, nor does it suggest alternatives like market_search_token or get_token_info_by_ticker for ticker-based lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds that it includes 'balances and market data' but does not disclose pagination behavior, whether zero balances are included, or how 'market data' is defined. With annotations covering the read-only nature, the description provides minimal additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the action, resource, and scope. There is no redundancy or filler. It is efficiently front-loaded with the verb 'List' and clearly conveys the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with well-documented parameters and no output schema, the description adequately conveys that the response includes token holdings, balances, and market data. However, it does not mention pagination or the shape of each item (e.g., token address, symbol, market cap), which would be useful given the absence of an output schema. Still, it is reasonably complete for a straightforward list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (chainId, address, page, pageSize) already described. The description does not add detail beyond the schema, except implying that the response contains token holdings and market data. Since the schema carries the parameter semantics, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all ERC-20 token holdings with balances and market data for an address.' It uses a specific verb 'List' and identifies the resource (ERC-20 token holdings) and the target (address). This distinguishes it from sibling tools like explorer_get_historical_balance or market_get_token_price by including both holdings and market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to get all token holdings and market data for an address. However, it does not explicitly state when to use this tool over alternatives (e.g., evm_get_token_balance for a single token or explorer_get_token_transfers for transfers). No exclusions or alternative tool names are mentioned, leaving the strategic selection to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint: true) already establish the non-destructive nature. The description adds the historical block context, but does not disclose return format, token decimal handling, or potential edge cases. It provides some value beyond annotations but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that conveys the core purpose and the key optional behavior. No filler or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, the description is largely adequate. It covers the main function and the historical variant. However, with no output schema, it does not explicitly state the return format (e.g., raw integer or string), which would ideally be included for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all parameters have clear descriptions. The description's mention of 'optional historical block' is redundant with the blockNumber schema description, so it does not add meaningful semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action 'Get' and a specific resource 'total supply of a token', with an optional historical block qualifier. It also distinguishes itself from sibling tools like explorer_get_native_supply by focusing on tokens and historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for both latest and historical token supply queries, but does not explicitly state when to prefer this over alternatives like get_token_total_supply or explorer_get_native_supply. The historical block mention gives a hint but lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, aligning with the read-only nature of the tool. The description adds the optional token contract filtering behavior but does not disclose pagination or block range constraints, which are left to the schema. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the key optional filter, and annotations cover the read-only safety. However, with 7 parameters and no output schema, the description could briefly mention that results are paginated and can be constrained by block range, though the schema covers these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions, so the baseline is 3. The description adds no additional parameter semantics beyond reiterating the tokenContract filter; it does not explain how startBlock/endBlock or page/pageSize interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('ERC-20 token transfer history for an address'), and notes the optional token contract filter. This clearly distinguishes it from siblings like explorer_get_nft_transfers or explorer_get_tx_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (retrieving ERC-20 transfers for an address) but does not explicitly state when to use this tool over alternatives or mention exclusions. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only and open-world behavior. The description adds minimal context about what 'execution status' means (errored or not), which is useful but not extensive. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that clearly communicates the tool's purpose without excess words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and complete schema coverage, the description is adequate. However, it does not specify the return format (e.g., boolean, status enum), though the phrase 'whether it errored' loosely implies it. Overall, it is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already fully describes both parameters (txHash and chainId) with clear descriptions and constraints. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('execution status of a transaction'), adding a clarifying parenthetical ('whether it errored during execution') that distinguishes it from sibling tools like get_tx_details and get_tx_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when querying execution status, but it does not explicitly state when to use it versus alternatives such as get_tx_receipt or get_tx_details. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('Get') and is annotated with openWorldHint=true, but it does not disclose additional behavioral traits such as error handling for unknown symbols, chain requirements, or potential rate limits. The annotation doesn't clearly cover these aspects either, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of 15 words, front-loads the key action, and has no filler. It effectively conveys the tool's purpose and return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with no output schema, the description names the return fields, which helps the agent anticipate the result. However, it does not mention the optional chainId parameter's effect or any error handling behavior, but those are captured in the schema. Overall, it's sufficiently complete given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has descriptions for both parameters (symbol and chainId), covering 100% of the schema. The tool description does not add additional parameter semantics; it merely repeats the 'by symbol' aspect already in the schema. So a baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function ('Get the ERC20 token info'), the lookup key ('by its symbol'), and the returned fields (contract address, decimals, name). This distinguishes it from siblings like get_token_info_by_ticker or explorer_get_token_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a token symbol, but it does not explicitly mention when to prefer this tool over similar alternatives such as get_token_info_by_ticker or explorer_get_token_info. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the output fields (chain IDs, names, native currencies) beyond the readOnlyHint annotation, but it does not disclose details like response size, ordering, or whether the list is static or dynamic. The annotation already covers the safety profile, so this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly and efficiently communicates the tool's purpose and output. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description is largely complete: it names the resource and the key output fields. It could be slightly more explicit about the return type (e.g., an array of chain objects), but that is reasonably implied by 'List all...'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and the rubric sets a baseline of 4 for zero-parameter tools. The description appropriately focuses on the output contents, which is the only semantic information an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource ('all supported EVM chains') and specifies the returned attributes: chain IDs, names, and native currencies. This distinguishes it from sibling tools like evm_get_chain_info, which provides details for a single chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as evm_get_supported_networks, lifi_get_chains, or list_chain_tokens. It states only what the tool does, not why or when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds the data source (DefiLlama) and return fields, but does not disclose other behavioral traits like caching, pagination, or rate limits. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word is informative. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema coverage and strong annotations, the description covers purpose, return fields, and available filters. It doesn't mention default limit or pagination behavior, but that's a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully explains chain, limit, and category parameters. The tool description adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the specific resource 'top DeFi protocols by TVL' from DefiLlama, and even enumerates the returned fields. This distinguishes it from sibling tools like market_get_top_tokens (tokens) and market_get_protocol_tvl (single protocol).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting ranked protocol TVL data but does not explicitly mention when to use alternative tools, such as market_get_protocol_tvl for a single protocol. There is no 'when not to use' guidance, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the source (CoinGecko search activity) and return structure, but no additional behavioral details like pagination or sorting. It adds some value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and resource, and no filler. Efficiently communicates purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description is adequate. It states the source, output fields, and the basis of trending. Minor missing context like sorting order or default limit is not critical given the annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'limit' with a complete description ('Maximum number of results to return'), so schema coverage is 100%. The description does not add extra parameter context, but the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches 'currently trending cryptocurrencies on CoinGecko based on search activity' and lists the returned fields (name, symbol, ID, market cap rank). The use of 'trending' distinguishes it from sibling market tools like top tokens or gainers/losers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for trending market data but does not explicitly mention when to use it over alternatives or any exclusions. With many sibling market tools, the context is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=true and destructiveHint=true, and the description adds that this resumes a previously prepared operation after external steps. It does not disclose additional behavioral traits like what state changes occur, rate limits, or errors, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the core purpose. No redundant words or filler, making it extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain what the tool returns, what happens on success/failure, or any prerequisites beyond 'previously prepared'. Given the complexity of resume operations and the destructive annotation, this lack of contextual detail leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema fully documents both resumeState and actionResults. The description adds no extra parameter meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resume') and the resource ('previously prepared external-wallet operation'), with a specific condition ('after signatures or transactions complete externally'). This distinguishes it from sibling tools like operation_prepare and orbs_prepare_swap_intent, which are about initiating operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it should be used after external signatures or transactions have completed. However, it does not explicitly mention when not to use it or name alternative tools, leaving the exclusion guidance implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds context about the data source (DefiLlama) and the ranked list output, but does not disclose sorting behavior, pagination, rate limits, or response size. With good annotations, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no filler. Every phrase contributes to understanding the tool's function and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (five optional params, no output schema), the description provides a reasonable summary of purpose, output fields, and data source. However, it lacks explicit guidance on ranking order or default limits, and does not mention related tools, so it is good but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters (chain, limit, token, minTvl, protocol) are documented in the schema. The description adds no parameter-specific detail beyond mentioning that the output includes APY, TVL, chain, and protocol, so it provides minimal added semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers DeFi yield farming and liquidity pool opportunities from DefiLlama's yields API, with a specific verb ('Discover') and resource. It also distinguishes itself by mentioning the filtered/ranked list with APY, TVL, chain, protocol, and pool metadata, setting it apart from broader market or research tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user wants yield farming or liquidity pool opportunities, but it does not explicitly state when to use it instead of alternatives like research_compare_yields. There are no exclusions or alternative recommendations, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already signals mutation, so the description does not need to restate that. It adds the useful behavioral detail that the tool returns operation details for execution, which hints at a two-step flow. However, it does not elaborate on side effects or irreversibility, though this is acceptable for a simple confirm action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that front-load the action and add a relevant return detail. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one documented parameter, a clear action, and a destructiveHint annotation, the description is mostly complete. It mentions the return value but does not detail the transaction lifecycle or prerequisites (e.g., the operation must be pending). This minor gap is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'id' parameter as a UUID of the pending operation, achieving 100% schema description coverage. The description adds no new parameter semantics beyond 'by ID', so the schema carries the burden and the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Confirm' and identifies the resource 'pending operation' by ID, clearly distinguishing it from sibling tools like transaction_deny and transaction_list. The second sentence clarifies the return value, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when confirming a pending operation—but does not explicitly mention alternatives like transaction_deny or transaction_list. The context of 'pending operation' gives some guidance, but no explicit exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already flag this as destructive/open-world, so the description does not need to restate that. It adds value by disclosing the internal behavior: auto-resolving a pending memo and signing approval. It stops short of mentioning irreversibility or failure modes, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose ('Complete a job'), then adds the key mechanism. No filler or redundant information; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a destructive action with no output schema, and the description does not explain what the caller should expect on success or failure. It does not mention prerequisites like an active wallet or funded job. The annotations and parameter schema cover some context, but the lack of return-value or side-effect detail leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and all parameters have brief descriptions ('Job ID', 'Completion reason', 'Chain ID (defaults to runtime config)'). The description does not add any additional parameter meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Complete a job') on a named resource ('Virtuals ACPRouter') and adds mechanism details ('auto-resolving the pending memo and signing approval'). This distinguishes it from sibling tools like acp_reject_job or acp_claim_refund.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for completing a job that has a pending memo to resolve, but it does not explicitly state when to use it versus alternatives like acp_reject_job or acp_get_job. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the description's 'mutating' aligns. It adds context about using a configured account and coverage of private write endpoints, but doesn't disclose additional behavioral traits like irreversibility of specific operations or error handling. This exceeds the annotation baseline slightly, but not substantially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the core action, the second adds scope. Every word contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic wrapper with no output schema, so description must convey scope. It covers main use cases but doesn't mention that returns vary by method or that some methods might require additional setup like loadMarkets (though that is in schema). The coverage list provides reasonable completeness for a wrapper of this type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described. The description doesn't add meaning beyond the schema; it mentions general categories but doesn't elaborate on how args/params map to specific CCXT methods beyond what schema descriptions already state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Invoke') and resource ('authenticated mutating CCXT method') and clearly distinguishes from siblings like ccxt_private_read and ccxt_public_call by specifying 'write' and listing mutating operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for authenticated mutating operations and lists covered categories (orders, cancellations, leverage, transfers, withdrawals). It doesn't explicitly name alternative tools for read-only or public calls, but the 'mutating' qualifier provides clear context for 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds that the call is public and can target implicit methods, but it doesn't describe return format, error behavior, or exchange-specific nuances. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the first stating the core action and the second adding a targeted usage tip. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a generic invocation tool with no output schema and 8 parameters, the description is minimal. It directs users to ccxt_describe_exchange for niche methods but doesn't mention return values, failure modes, or the relationship to specialized market data tools; annotations mitigate safety but not retrieval semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the description doesn't need to restate them. The only added semantic clarification is 'unified or implicit' methods, which is also already present in the method parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'invoke' and identifies the resource: public CCXT unified or implicit methods on a selected exchange. It clearly distinguishes from siblings by explicitly limiting to public methods, with private counterparts present as sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance to call ccxt_describe_exchange first for capability discovery on niche methods, naming the relevant sibling tool. However, it doesn't broadly contrast this with the many specialized market_get_* tools or state exclusions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (openWorldHint, destructiveHint), the description discloses the critical requirement of wallet + confirmation, which is essential for an agent to invoke it safely. This adds value by preventing failed attempts and clarifying the operation's irreversible nature in combination with destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence delivers the core purpose and the key prerequisite. No wasted words; the parenthetical adds essential operational context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary operational constraint (wallet + confirmation) but omits return value details or post-registration behavior. With 6 parameters and no output schema, it leans on the schema but leaves the agent uncertain about what to expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage, including descriptions for name, chainId, agentURI, services, description, and mcpEndpoint. The description adds no extra parameter semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Register an agent on the ERC-8004 Identity Registry'. It distinguishes from siblings like erc8004_get_agent and erc8004_update_agent via the unique 'register' verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by noting it is a write operation requiring wallet + confirmation, but it does not explicitly contrast with erc8004_update_agent or provide when-not-to-use guidance. The context is clear enough for an agent to infer it is for new registrations, but it lacks explicit alternative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds no additional behavioral details such as pagination, ordering, or return format, so it remains at the baseline for a read-only tool with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 8 parameters, the description is adequate but does not describe return values or differentiate from the similarly named explorer_get_event_logs_by_topics. Given the missing output schema and sibling ambiguity, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (address, chainId, topic0-3, startBlock, endBlock) are already documented. The description's mention of 'topics and block range' summarizes schema content but adds no new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves event logs emitted by a specific contract address, with optional filtering by topics and block range. This distinguishes it from sibling tools like explorer_get_event_logs_by_topics by emphasizing the address-specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it—for event logs from a specific contract with optional filters—but does not explicitly mention alternatives or when not to use it. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds the 'daily' granularity, which is useful behavior context. However, it does not disclose response format, potential limitations, or other behaviors. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence. It wastes no words and immediately communicates the tool's action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must compensate. It states the core function but does not specify the return format (e.g., array of daily prices) or any constraints. The sort parameter in the schema implies a list result, making the description minimally sufficient, but more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with clear formats. The description adds context by noting 'daily' and 'native token', which clarifies that startDate/endDate should be used for daily price queries and that chainId refers to a chain's native token. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get'), resource ('historical daily native token prices'), and scope ('date range'). It distinguishes itself from siblings like explorer_get_native_price (current price) and market_get_token_history (any token) by specifying 'native' and 'daily'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the tool's function, but it does not explicitly mention when to use it over alternatives like market_get_token_history or explorer_get_native_price. There is no guidance on exclusions or alternative tools, which is a gap given many similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, which already signal safety and external interaction. The description adds useful context beyond annotations: it returns 'next actions plus opaque resume state', indicating a two-part result and that the operation is not directly executed. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose and return information. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (four distinct operation kinds, no output schema), the description provides a high-level overview but misses key context: it does not mention the operation kinds (swap, order, bridge, tool) explicitly, nor does it explain how the opaque resume state should be used (e.g., with operation_resume). The schema covers the parameters, but the description alone would not fully guide an agent through the prepare-with-resume flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for parameters, with detailed descriptions for each field across all four operation variants. The tool description adds no additional parameter semantics beyond what the schema offers, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('prepare') and resource ('external-wallet operation') and immediately names the three target integrations (Orbs, LI.FI, GOAT). It also states the return value (next actions plus opaque resume state), making the tool's purpose clear and distinct from direct execution tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool — when preparing an external-wallet operation for the named integrations. However, it does not explicitly differentiate between this generic prepare tool and the many specific sibling prepare tools (e.g., orbs_prepare_swap_intent, lifi_prepare_bridge_intent), nor does it state when not to use it or which alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds return fields and a use case, but no additional behavioral traits like pagination limits or data freshness. It is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant phrases. The first sentence names the action and source; the second lists expected output fields and a use case. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explicitly lists the primary return fields (project name, date, USD amount, funding round type, lead investors). For a simple one-parameter tool with rich annotations, this information is sufficient for an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'limit' is fully described in the schema ('Maximum number of results to return'). The description offers no additional parameter detail, but with 100% schema coverage, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches fundraising and investment round data from DefiLlama, with a specific verb ('Fetch') and resource, and lists return fields (project name, date, USD amount, round type, lead investors). This distinguishes it from sibling research tools like research_token_holders or research_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage through its scope (fundraising rounds) but lacks explicit exclusions or alternative tool references, such as 'for security audits use research_contract_security'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful conditional behavior (CoinGecko-listed token -> extra dev/community/sentiment data) and source, but does not disclose failure modes, output format, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and list key return fields, with the conditional added in the second sentence. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only info tool with rich annotations and full schema coverage, the description sufficiently explains what the tool returns and the conditional enrichment. No output schema is present, but the description acts as a return-value summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'protocol' parameter as a DefiLlama slug with examples. Since schema coverage is 100%, the description adds no further semantic value; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('detailed information about a DeFi protocol'), enumerating specific data categories (TVL, chain breakdown, category, audit history, funding rounds) and source (DefiLlama). This clearly distinguishes it from sibling research tools like research_contract_security or market_get_protocol_tvl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates the tool's scope and data source, implying use when a comprehensive protocol profile is needed. However, it does not explicitly state when to prefer this over related tools (e.g., research_fund_raises, research_contract_security) or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral details beyond annotations: it uses RPC trace when available and falls back to static decoding for token balance changes. This explains the execution mechanism and output focus, though it doesn't specify failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the primary action and method, with no redundant words. Every phrase earns its place by conveying the simulation approach and fallback behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and simulation method, but since there is no output schema, it does not explain the return format or how to interpret results beyond mentioning token balance changes. Given the tool's moderate complexity and read-only nature, this is a noticeable gap but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all five parameters (chainId, to, data, from, value) described in the schema. The description adds no additional parameter-level explanation, but it does clarify that the output relates to token balance changes, which is indirectly useful. Baseline of 3 applies because the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as simulating an unsigned transaction, with a specific verb ('Simulate') and resource ('unsigned transaction'). It also distinguishes itself from sibling tools like transaction_confirm/transaction_deny by emphasizing the simulation aspect, and from read tools like evm_read_contract by focusing on transaction execution simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the core use case (simulating an unsigned transaction) and hints at a fallback behavior, but does not explicitly state when to choose this tool over alternatives or mention any exclusions. Context implies it is for pre-signing preview, but there is no explicit 'use this instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful behavioral context by listing what data is returned (phase, participants, budget, memos with status). However, it claims 'full memo history' without disclosing that the memoLimit parameter (default 100) can cap the number of memos returned, which is a minor transparency gap beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and then elaborating with specific output details. Every word adds value, with no filler or repetition. It is concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (phase, participants, budget, memos with status). It also provides enough context about the ACPRouter domain. It could additionally mention default behaviors for memoLimit and chainId, but these are covered in the schema, so the description is reasonably complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so parameters are fully documented there. The description does not add much beyond the schema, only implicitly referencing jobId and hinting at memo history. Baseline of 3 is appropriate since the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('Get') and resource ('job details and full memo history from the Virtuals ACPRouter'). It distinguishes itself from siblings like erc8183_get_job by naming the ACPRouter context and enumerates key returned fields (phase, participants, budget, memos with status), making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (specifically for ACPRouter jobs) and implies when to use this tool, but it does not explicitly state when not to use it or mention alternatives. The naming and context are sufficient for an AI agent to infer appropriate usage among the many sibling tools, but explicit exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as a read operation; the description adds the meaningful constraint that an active wallet is required, which is not captured in the annotations. It does not describe return format or edge cases, but given the safety annotation, this additional context raises it above baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using only two sentences to convey both the action and a key prerequisite. It is front-loaded with the primary purpose, and every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description covers the essential purpose and a critical prerequisite, and the schema handles the parameter. It could be enhanced by mentioning the return type, but the overall context is sufficient given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'status' parameter with an enum and description, so the description adds no new parameter semantics. The mention of 'active or completed' mirrors the schema, providing no additional value beyond the structured definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the user's active or completed jobs from the aGDP marketplace, using a specific verb ('List') and resource. This distinguishes it from sibling tools like agdp_get_offerings and erc8183_get_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for viewing jobs associated with the caller, and notes the wallet requirement, but it doesn't explicitly compare with alternative tools or state when not to use. For example, it doesn't clarify differences from erc8183_get_job or acp_get_job, leaving usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds little beyond that, only stating 'detailed information' without disclosing error behavior, return format, or any constraints. With annotations covering the safety profile, the description adds marginal behavioral context but not rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the purpose and includes the key identifier mechanism ('by ID'), making it concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-by-ID tool with one parameter, high schema coverage, and read-only annotations, the description is nearly complete. It lacks an explicit mention of return content, but since no output schema is provided and the operation is straightforward, this is a minor gap. The cross-reference to agdp_get_offerings in the parameter description completes the contextual picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter offeringId has a description 'Agent ID from agdp_get_offerings'. The tool description does not add further meaning beyond 'by ID', and the schema already explains the source and format. Baseline 3 applies because the schema carries the full semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get detailed information about a specific agent offering by ID.' It clearly distinguishes from the sibling tool agdp_get_offerings by emphasizing 'specific' and 'by ID', so the agent can differentiate the list tool from the detail tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description itself doesn't mention alternatives, but the parameter schema explicitly says 'Agent ID from agdp_get_offerings', implying a workflow: first list offerings, then get details on one. This provides clear contextual guidance on when to use this tool, though it doesn't explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint and openWorldHint, and the description adds valuable operational context: it is a write operation requiring a wallet and confirmation. This goes beyond the annotations by stating prerequisites and the side-effect nature, though it does not detail all consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, with zero wasted words. It is concise and structured effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers all parameters and annotations indicate risk, the description provides enough context for a feedback submission tool. It covers the essential operational requirement (wallet + confirmation) and the tool's purpose, which is sufficient for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all six parameters are already explained. The description does not add parameter-specific details, only the overall purpose. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Submit reputation feedback' with a specific target (ERC-8004 agent). This verb+resource combination is unambiguous and differentiates it from sibling tools like erc8004_get_feedback or erc8004_update_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention alternatives or when-not-to-use conditions, but it does indicate this is a write operation requiring wallet and confirmation, which implies the appropriate context for use. It lacks explicit exclusions but the intent is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true. The description adds that the refund applies to expired/rejected jobs, which is useful context. However, it does not disclose potential side effects (e.g., on-chain transaction, fund transfer), whether it requires ownership, or what happens if the job is not in the expected state. With annotations covering the destructive nature, a mid-score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It contains no filler and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is nearly sufficient. It states the condition (expired/rejected) and the action (claim refund). It lacks any details about expected results or prerequisites (e.g., connection to the job creator), but given the simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has descriptions for both parameters (jobId and chainId), with 100% coverage. The tool description adds no additional parameter-specific information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Claim refund' and a specific resource 'expired/rejected ERC-8183 job'. It clearly states the action and the condition, and the ERC-8183 prefix distinguishes it from the sibling acp_claim_refund.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a job is expired or rejected. It provides a clear context, but it does not explicitly say 'use this instead of acp_claim_refund' or mention when not to use it. Nonetheless, the 'expired/rejected' qualifier gives adequate guidance for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and openWorldHint, so the agent knows this is a safe, non-mutating operation. The description adds no extra behavioral context beyond what the schema already provides (e.g., return format, possible errors, or rate limits). It does not contradict annotations, but it contributes little additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. No unnecessary words or redundant information. It earns its place by being clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with full schema coverage and relevant annotations, the description is sufficient. One could argue that it doesn't list what fields are included in 'job details', but there is no output schema and the tool's purpose is self-evident. It is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both jobId and chainId having meaningful descriptions (e.g., jobId is 'Job ID', chainId defaults to runtime config). The tool description repeats the 'by ID' aspect but does not add further meaning beyond the schema. Baseline is 3 for high coverage, and this description does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the target resource ('ERC-8183 job details'), with the lookup key ('by ID'). It is unambiguous and distinguishes itself from sibling mutation tools like erc8183_create_job or erc8183_fund_job by indicating a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage context: it is the appropriate tool when one needs to fetch details of a specific ERC-8183 job by its ID. It does not explicitly state when not to use it or mention alternatives, but the naming and read-only nature make the intended usage clear, and no exclusions are needed for such a straightforward getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares that this is a safe read operation, and the description adds no further behavioral context (e.g., return format, potential variability). Since the tool is simple and the annotations cover safety, the description meets the minimum bar but does not enrich beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the action and resource, making it immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool with good annotations, the description is adequate. It could be slightly more specific about what the response looks like (e.g., network names, IDs), but the overall context of discovering supported networks is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty properties object). The description does not need to explain parameter behavior, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('List'), the resource ('supported EVM networks'), and the context ('available for EVM tool operations'). It is distinct from sibling tools like market_get_chain_tvl and evm_get_chain_info, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used to discover which EVM networks are available before performing other EVM operations. However, it does not explicitly mention alternatives or when not to use it, leaving some ambiguity relative to similar tools like list_supported_chains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint annotations already present, the description adds minimal behavioral context. It mentions 'multicall RPC request' but does not disclose failure handling behavior or return format, which could be relevant given the allowFailure parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary purpose, and contains no redundant words. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully documents parameters and annotations cover read-only safety, the description is largely sufficient for a simple batch read tool. However, the lack of output schema and absence of return format in the description is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are adequately documented in the schema. The description itself repeats no parameter details, but the baseline is 3 due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool batches multiple contract read calls into a single multicall RPC request, using a specific verb and resource. It distinguishes itself from single-call tools like evm_read_contract and write tools like evm_write_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when multiple contract reads need to be batched, and clearly indicates it is for read calls only, excluding write operations. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims to 'Register a contract ABI under a label for reuse,' which implies a stateful write operation, but annotations include readOnlyHint=true. This contradicts the read-only hint and misleads the agent about side effects. The description also does not clarify what happens on duplicate labels or whether registration persists across sessions, but the contradiction alone warrants a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, followed by a practical reuse instruction. Every sentence earns its place, with no unnecessary details or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the essential purpose and integration points well. It does not address edge cases like duplicate labels or persistence, but the system context and schema suffice. The annotation contradiction slightly undermines completeness, but the description is otherwise adequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter coverage, so the baseline is 3. The description adds value by explaining that the 'label' parameter becomes the 'abiLabel' used in dependent tools, providing contextual meaning beyond the schema's brief description. This helps the agent understand how the parameters connect to the broader tool ecosystem.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Register') and resource ('contract ABI'), clearly distinguishing it from other EVM tools. It explicitly mentions the label mechanism and names the dependent tools (evm_read_contract, evm_write_contract, evm_multicall), leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: register an ABI once to avoid repeating the full ABI JSON on subsequent calls. It clearly states the context of use and how it connects to alternative tools, making it easy for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safe read-only and external dependency aspects. The description adds that it waits for confirmations and returns a receipt, but doesn't disclose potential delays, timeouts, or failure behavior, which is a common concern for waiting operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that fully captures the tool's essence without fluff. It is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and strong schema/annotation coverage, the description is nearly complete. It states the core behavior and outcome (returning the confirmed receipt), but does not detail edge cases like timeout or transaction failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any meaning about the parameters beyond what the schema already provides (e.g., defaults for confirmations, chainId behavior).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('wait for') and resource ('transaction confirmations') and states the outcome ('return the confirmed receipt'). It clearly distinguishes this from siblings like evm_get_transaction_receipt by emphasizing the waiting behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage: you call this when you need to wait for confirmations and get a receipt. However, it does not explicitly mention alternatives or exclusions, such as when to use evm_get_transaction_receipt instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that it returns the earliest transaction, but it does not explain semantics such as how 'earliest' is defined (by block number or timestamp), what happens if no transactions exist, or whether the full transaction object is returned. With annotations present, the description adds moderate but limited behavioral context beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and purpose without wasted words. It is concise, directly readable, and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two well-documented parameters, good annotations, and a straightforward behavior, the description covers the essential purpose. The only mild gap is that it does not specify the return shape or the exact ordering criterion for 'earliest', but this is a minor omission given the tool's simplicity and the sibling tool context. Overall, the description is sufficiently complete for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters (chainId and address) have descriptive text in the schema. The description does not add any parameter-level detail beyond the schema, such as formatting examples or constraints. Since the schema already handles parameter semantics comprehensively, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the earliest transaction for an address, using a specific verb ('Get') and resource ('earliest transaction'). It also adds purpose ('useful for identifying initial funding or activity'), and this tool's scoped focus (earliest transaction) distinguishes it from sibling tools like explorer_get_tx_history or explorer_get_tx_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: identifying initial funding or activity for an address. It does not explicitly mention alternatives or exclusions, but the purpose is clear enough that an agent could infer when to use this over the broader transaction history tool. However, it lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description is consistent and adds the specificity of historical block scoping, but it does not disclose additional behavioral details such as return format (e.g., wei vs ETH), error handling for invalid blocks, or any rate limits. Thus it meets the baseline but adds limited extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 14 words is exceptionally concise and fully front-loaded with the core action. Every word earns its place, meeting the gold standard for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 all-required params, no nested objects) and the annotations covering safety, the description is largely complete. It clarifies the purpose and all parameters are documented. However, with no output schema, it would be slightly more complete if it mentioned the return unit (e.g., wei), but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, with each parameter described (chainId, address, blockNumber). The description does not add any parameter information beyond the schema, so it earns 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the exact resource ('native token balance of an address'), and scopes it to 'a specific historical block number.' This clearly distinguishes it from sibling tools like explorer_get_historical_token_balance (which handles token balances) and evm_get_balance (which is for current balances).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when a historical native token balance is needed. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the ERC-20 and historical block specifics, but these are more about input parameters than behavioral traits like error handling, return format, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is clear, front-loaded with the verb 'Get', and contains no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query with complete schema documentation and annotations, the description is sufficient. It lacks explicit return format details (no output schema), but the purpose is clear. Slightly more could be added about units or response shape, but not necessary for basic usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description reinforces that blockNumber is historical and that the target is an ERC-20 balance, but adds no parameter-specific details beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'ERC-20 token balance', and the specific scope 'of an address at a specific historical block number'. It distinguishes from sibling tools like explorer_get_historical_balance (likely native balance) and evm_get_token_balance (current balance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool for historical ERC-20 token balances. It does not explicitly mention alternatives or when-not-to-use, but the historical and ERC-20 qualifiers imply the appropriate use case versus other balance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds no extra behavioral context like rate limits or error handling, but for a simple read-only price lookup the minimal description is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the tool's purpose without any filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description sufficiently indicates return values (USD and BTC prices). It lacks details about chain support or format, but the tool is simple enough that this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes chainId with a clear description (100% coverage). The tool description adds no additional parameter meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('current native token price') with explicit units (USD and BTC). It distinguishes itself from siblings like market_get_token_price (which likely covers any token) and explorer_get_historical_price (historical data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (native token price, current) but does not explicitly mention alternatives or when-not-to-use. The context is sufficient for an agent to infer usage, but lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description unambiguously conveys a read-only operation ('Get'), consistent with the openWorldHint annotation. It adds useful context about the scope (native vs. ERC20 token) without introducing any contradictions or hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that precisely states the tool's function with no unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple read-only tool with no output schema. However, it does not help the agent distinguish this tool from similar sibling tools like evm_get_balance or get_token_balance, which would be a useful addition but is not strictly required given the straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage), so the description adds no additional meaning beyond what the schema already provides. The reference to native currency and ERC20 tokens is duplicated in the tokenAddress field description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with the specific resource 'balance of the wallet,' and clearly differentiates between native currency and a specific ERC20 token. This is not a tautology and distinguishes the tool from broader or less specific operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as evm_get_balance or get_token_balance, nor does it mention exclusions. It implies usage for checking wallet balances but provides no explicit contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate that. The description adds the LI.FI-specific context and the purpose, but doesn't disclose additional behavior such as response format, pagination, or rate limits. Since this is a simple read-only list, the description suffices but doesn't go beyond the annotations significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the action verb 'Get'. Every word earns its place, and there is no unnecessary information. It is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description is complete enough: it states what chains are returned (LI.FI-supported for cross-chain bridging). There is no output schema to explain return values, but the tool's output is easily inferred. A minor gap is the lack of detail on the exact format of the chain list, but the description is still adequate for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description doesn't need to explain parameters, and the baseline for 0-parameter tools is 4. The description adds value by clearly defining what the tool returns without needing parameter elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('list of chains supported by LI.FI for cross-chain bridging'), which immediately distinguishes it from generic chain listing tools and other LI.FI tools. The qualifier 'for cross-chain bridging' makes the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description—if you need the list of chains LI.FI supports for bridging, this is the tool—but there is no explicit guidance on when to choose this tool over alternatives, nor any mention of exclusions or sibling tools. The purpose is clear, so a score of 3 (implied usage) is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds context about supported chains and the dependency on token addresses, which is helpful. However, it does not disclose return format, pagination, rate limits, or any other behavioral traits beyond what annotations imply. With annotations covering the core safety, a score of 3 is appropriate for the additional context provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: stating the function, listing supported chains, and giving a prerequisite. No filler or redundancy. The description is front-loaded with the core action and efficiently covers necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a read-only quote fetcher with fully documented parameters and no output schema. The description covers the core action, chain support, and a prerequisite. It is missing a note about how the quote fits into the broader workflow (e.g., that it should be followed by lifi_execute_bridge or lifi_prepare_bridge_intent), but given the simplicity of a quote tool, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — all five parameters have descriptive comments (e.g., 'Source token address', 'Amount in smallest token units'). The description adds the note to use resolve_token first, which reinforces addressing but does not add new parameter-level meaning. Since the schema carries the full burden, the baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get a cross-chain bridge/swap quote from LI.FI.' It names a specific verb ('Get'), a resource ('quote'), and a source ('LI.FI'), which differentiates it from execution tools like lifi_execute_bridge and other providers like orbs_get_quote. The chain support list adds specificity without obscuring the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Requires token addresses — use resolve_token first to get addresses.' This guides the user on a necessary step before calling the tool. It also implies a usage context (getting a quote before executing a bridge), though it doesn't explicitly state when not to use it or compare it to alternatives like orbs_get_quote. The guidance is useful but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description only needs to add contextual behavior. It adds the data source (DefiLlama CEX tracker) and indicates return content (inflow/outflow amounts), but it does not disclose details like default limit behavior, ordering, or time range. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the action and resource, and avoids filler. Every clause contributes useful context about the data source and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, rich annotations, and no output schema, the description sufficiently covers tool purpose and return content. It could mention time range, units, or sorting, but for a simple retrieval tool it is complete enough to guide correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'limit' is already fully described in the schema as 'Maximum number of results to return', so schema coverage is 100%. The description adds no additional meaning about the parameter, matching the baseline where the schema carries the explanatory burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Fetch' and clearly identifies the resource: net fund flow data for centralized exchanges from DefiLlama's CEX tracker. It also states the output includes inflow and outflow amounts per exchange, which distinguishes it from sibling market tools like market_get_exchange_rankings or market_get_dex_volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'useful for monitoring capital movements on CEXes.' It does not explicitly name alternatives or exclusion criteria, but the CEX-specific scope makes the intended context reasonably clear without needing extensive comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context about the data source (DefiLlama), the ranking of results, and the specific volume figures included, which are not present in the annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action and output format. Every word contributes to understanding the tool's purpose, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional filters and no output schema, the description adequately specifies the return value (ranked list with daily and total volume) and the data source. It doesn't cover edge cases like unfiltered requests, but given the tool's low complexity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (chain and protocol) are fully described in the schema with clear descriptions. The tool description doesn't add additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches 24-hour trading volume data for decentralized exchanges from DefiLlama, specifying it returns a ranked list with daily and total volume figures. This distinguishes it from sibling tools like market_get_exchange_rankings or market_get_cex_fund_flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for DEX volume data but does not explicitly state when to use this tool over alternatives or mention exclusions. It provides context (source and metrics) but lacks direct guidance on choosing between this and similar market tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds detail about returned fields (name, assets, volume metrics) but does not disclose additional behavioral traits like sorting order, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second lists return fields. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description covers the core purpose, data source, and return fields. It lacks details about default limits or sorting, but given the annotations and schema, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the single 'limit' parameter. The tool description does not add parameter-specific meaning, so the schema provides all necessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve'), the subject ('centralized exchanges'), the source ('DefiLlama'), and the ranking criterion ('assets under management'). It also lists the return fields, making it distinct from sibling market tools like market_get_top_protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about the tool's purpose (exchange rankings) but does not explicitly mention alternatives or when not to use it. However, the specific language about centralized exchanges and rankings is sufficient for an agent to select it when exchange ranking data is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description only adds the data scope (global TVL), which is essentially part of the purpose, and does not disclose additional behavioral traits such as data freshness, rate limits, or response size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the action and expected result without any unnecessary words or repetition. It earns its place completely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description provides adequate context by specifying that it returns total DeFi TVL globally. An output schema is absent, so a bit more detail on the response format could help, but for a simple statistics endpoint this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is complete. With no parameters to explain, the description does not need to add parameter semantics, and a baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Fetch aggregate global DeFi market statistics') and resource ('DefiLlama'), and explicitly mentions the return value ('total DeFi TVL across all chains and protocols'). This distinguishes it from sibling tools that focus on individual chains or protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for a macro view of the DeFi ecosystem, but does not explicitly state when to use this tool versus alternatives like market_get_chain_tvl or market_get_top_protocols. No exclusionary or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context beyond annotations by specifying the return fields and data source (CoinGecko). It does not mention result limits, ordering, or no-match behavior, but the annotation coverage lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The description is front-loaded with the action verb and every phrase adds information about scope or return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-parameter search tool with rich annotations, the description covers the essentials: what is searched and what is returned. However, it is slightly ambiguous whether returns include exchanges/NFTs or just coins, and it omits result limits or pagination. Since there is no output schema, the description carries the return-format burden, which it handles adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the query parameter fully described as 'token name, symbol, or keyword'. The description merely restates keyword searching without adding format examples, syntax details, or additional semantics beyond the schema, so it meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Search), the resource scope (cryptocurrencies, exchanges, and NFTs on CoinGecko), and the return value (CoinGecko ID, symbol, name, market cap rank). This is a specific verb+resource that distinguishes it from sibling getter tools like market_get_token_price or market_get_top_tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—keyword-based discovery of CoinGecko assets—but does not explicitly state when to prefer this tool over similar lookup/resolution tools such as get_token_info_by_ticker, resolve_token, or dexscreener_search_pairs. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description only needs to add extra behavior. It does this by specifying that the tool returns EIP-712 typed data, approval calldata, and metadata, and that signing happens externally. This clarifies the non-mutating nature and output format beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and summarizes the outputs without unnecessary detail. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a preparation tool with no output schema, the description names three key return components (EIP-712 data, approval calldata, metadata) and mentions external wallet signing. It could be improved by indicating the follow-up step (e.g., using a submission tool), but the name and describe intent are sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters are already documented in the schema with descriptions. The tool description does not add any parameter-level information, which is acceptable given the high coverage. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Prepare') and resource ('limit order'), clearly distinguishing it from sibling tools like orbs_swap and orbs_place_limit. It also mentions the key output (EIP-712 data, approval calldata, metadata) which further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for external wallet signing' implies this is a preparation step, not a submission step, and the presence of siblings like orbs_submit_signed_order hints at a workflow. However, it does not explicitly state when to use this tool versus the direct order placement tool (orbs_place_limit) or mention any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds useful behavioral context by specifying the exact return artifacts and the fact that it prepares rather than executes. It does not contradict annotations, and 'prepare' aligns with the read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the primary verb and resource, and every phrase adds value. No fluff or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and no output schema, the description adequately summarizes the return payload and order-type coverage. However, it does not explicitly mention the subsequent submission step (e.g., via the returned submit URL or orbs_submit_signed_order), which would be helpful for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 14 parameters individually described. The tool description adds no further parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (prepare a Spot order), the context (external wallet signing), and the deliverables (EIP-712 typed data, approval calldata, submit URL, order metadata). The phrase 'Supports all order types' distinguishes it from specialized sibling tools like orbs_prepare_twap_intent and orbs_prepare_limit_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'for external wallet signing' and the listed return artifacts, but the description does not explicitly state when to choose this tool over alternatives like orbs_prepare_swap_intent or when not to use it. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description doesn't need to restate those. It adds value by disclosing the return fields (article titles, publication dates, source names, URLs) and describing the output as a 'curated feed.' However, it omits potential behavioral details like default limit, ordering, or whether results are paginated, which would make it more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the verb and resource, then concisely lists return fields and the intended use case. Every sentence earns its place, making it both efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the core behavior: what it retrieves, what it returns, and the use case. It could mention how the `limit` parameter affects results, but the overall completeness is strong given the tool's simplicity and rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter `limit` is fully described in the schema as 'Maximum number of results to return,' giving 100% schema coverage. The description adds no extra meaning about this parameter, so the baseline score of 3 is appropriate since the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'crypto and DeFi news headlines from DefiLlama's news aggregator.' It distinguishes itself from sibling research tools (e.g., research_token_holders, research_contract_security) by focusing on news headlines rather than on-chain analytics, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the tool 'support[s] market research and situational awareness,' implying when to use it. However, it does not explicitly mention when not to use it or point to alternative tools, so it falls short of the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety and mutability. The description adds that the tool aggregates from 'multiple sources' and returns a 'structured risk assessment', which gives useful context. However, it does not disclose potential latency, external API dependency, or rate-limit behavior, so a 3 is appropriate given the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function, followed by a succinct breakdown of the output and purpose. Every sentence adds value and there is no redundancy or wasted words. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is no output schema, the description enumerates the key output components (contract safety flags, top holder concentration, liquidity metrics), giving the agent a clear picture of the result. It does not elaborate on potential failure modes or multi-chain specifics, but given the simplicity of the parameters and the aggregated nature, it is sufficiently complete for tool selection and invocation. A higher score would require more detail on data sources or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: 'token' is clearly described as 'Token address or symbol to investigate' and 'chainId' as 'Chain ID (defaults to runtime config)'. The description does not add new parameter-specific semantics, but the schema already handles them well. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('perform comprehensive due diligence') and resource ('on a token'), and it distinguishes itself from siblings by aggregating security, holder distribution, and market data into a single risk assessment. This is a specific and well-scoped purpose, differentiating it from tools like research_contract_security or market_get_token_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a holistic research use case ('comprehensive due diligence') but does not explicitly contrast with sibling tools such as research_contract_security or research_token_holders. It provides clear context on what the tool covers, but lacks explicit 'when not to use' or alternative guidance. This earns a 4 for clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the burden is lower. The description adds meaningful behavioral context by specifying the data source (GoPlus Security) and the return payload (ranked holder addresses with balance and percentage share). It does not contradict annotations and goes beyond them by clarifying the data provenance and output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action and data source, the second explains the output and purpose. Every word contributes to understanding the tool. There is no fluff or repetition, and the structure is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only data retrieval tool with a fully described schema and helpful annotations, the description covers the essential aspects: what it does, the data source, the output format, and a use case. It does not specify details like pagination or default chain behavior, but these are either in the schema or not critical for a top-holders query. The description is complete enough for an agent to select the tool correctly, especially given the schema and annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with 100% description coverage, so the baseline is 3. The description adds minimal additional value for parameters: it reinforces that 'token' is a contract address but does not elaborate on 'limit' or 'chainId' beyond what the schema already states. Since the schema already does the heavy lifting, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Retrieve the top token holders for a given contract address using GoPlus Security data.' The verb 'retrieve' is specific, the resource is concrete, and the mention of GoPlus Security distinguishes it from similar tools like explorer_get_top_token_holders. The description also details the output (ranked list with balance and percentage) and intended analysis, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context ('enabling analysis of holder concentration and whale exposure') but provides no explicit guidance on when to use this tool versus alternatives such as explorer_get_top_token_holders or research_token_due_diligence. It does not mention exclusions or conditions that would make another tool more appropriate. The differentiation via GoPlus Security data source is present but not leveraged into clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include idempotentHint, so the description carries the burden of behavioral disclosure. It adds the key fact that the operation is not executed and is removed, which is helpful. But it omits whether the removal is reversible or what happens if the ID does not exist, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that delivers all essential information with no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description effectively covers the core action and the key nuance of non-execution. It could elaborate on post-denial effects, but the simplicity of the tool makes the description largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the id parameter fully (100%), so the baseline is 3. The description's mention of 'by ID' aligns with the schema but adds no extra semantic detail beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb 'Deny and remove' and clearly identifies the resource as 'pending operation by ID'. This unambiguously distinguishes it from transaction_confirm, which approves instead of denies, and transaction_simulate, which tests without permanent action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without executing it' immediately conveys that this tool is for cancellation rather than execution, providing clear context. However, it does not explicitly name alternatives or state when not to use it, but the contrast with transaction_confirm is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavior: enabling queues writes for confirmation. However, it does not elaborate on the destructiveHint annotation, such as the potential risk of disabling confirmation (allowing writes to execute immediately without review). IdempotentHint is consistent with the toggle behavior. The description adds some value but leaves the destructive aspect unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences, immediately stating the action and the consequence. No filler or redundant content, every word earns its place. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single boolean parameter) and full schema coverage, the description is largely complete. It covers the primary behavior and the runtime aspect. The only gap is the lack of mention about the interaction with confirmation/deny tools and the potential risk of disabling confirmation, but this is not critical for a simple toggle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description clearly defines 'enabled' semantics. The description repeats the same information ('when enabled...') without adding new meaning. It does not compensate beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Toggle write confirmation at runtime.' It specifies the resource (write confirmation) and the verb (toggle), making it distinct from siblings like transaction_confirm (which confirms specific transactions) and wallet_activate/deactivate (which manage wallet state). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: to toggle whether write operations are queued for confirmation. It explains the effect of enabling ('write operations are queued and require explicit confirmation'), but does not explicitly mention when not to use it or name alternatives. Since there is no direct alternative for toggling this setting, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the ERC-20 vs native distinction, but does not disclose other behavioral aspects like return format (raw vs decimal-adjusted), error cases, or chain defaults. It provides some value beyond annotations but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, then a requirement, then an alternative. Every sentence serves a distinct function and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with good schema and annotations, the description covers the core purpose and usage. However, it does not specify the return value format (e.g., raw integer vs. decimal-adjusted), which is a notable gap since there is no output schema. The description is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description's mention of 'token contract address' and 'owner address' restates schema information without adding new meaning. No extra details on formats, defaults, or examples are provided, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets ERC-20 token balances for an owner address, specifying verb, resource, and scope. It distinguishes itself from evm_get_balance by explicitly noting native balances should use the alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool (for ERC-20 tokens) and when not to (native tokens, with a specific alternative named: evm_get_balance). It also emphasizes the requirement of a token contract address, giving clear prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that it returns raw transaction steps, confirming non-execution and providing output context. It doesn't mention rate limits or errors, but the added value is sufficient given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and a clear return-value statement. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the core purpose but doesn't detail the output structure or the flow after preparation (e.g., whether steps include approvals or how they should be used with an execution tool). Since no output schema exists, the description could be richer, but it's adequate for understanding the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters already have descriptions in the schema. The description itself adds no parameter-specific information, which is acceptable per the baseline of 3 when schema covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'prepare', the resource 'cross-chain bridge route', and the key distinction that it returns raw transaction steps without executing. This differentiates it from lifi_execute_bridge (which executes) and lifi_get_quote (which only quotes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to prepare a bridge route for an external wallet without executing. It doesn't explicitly name alternatives, but the 'without executing them' and 'external wallet' provide clear context. It could be more explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safe, read-only nature is established. The description adds value by specifying the data source (alternative.me), the output (current index value plus historical daily readings), and the effect of the days parameter. This provides useful context beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and then adding return details. Every clause contributes meaningful information, with no redundancy or filler. It is appropriately concise for a simple read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description sufficiently explains what is returned (current index value, classification, and historical daily readings) and mentions the data source. Given the low complexity and strong annotations, the description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'days' parameter, and the schema already provides a detailed description including default and max values. The tool description adds little beyond referencing 'recent days' and implying that the parameter controls history length, which is already covered by the schema. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Fetch', the exact resource 'Crypto Fear & Greed Index from alternative.me', and the scope ('for the specified number of recent days'). It also differentiates this from sibling tools that handle protocols, tokens, or DEX data, making the tool's unique purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description clearly implies this tool is for retrieving market sentiment via the Fear & Greed Index, it does not explicitly state when to use it over alternatives, nor does it mention exclusions. There is no guidance like 'Use this for sentiment, and X for token prices'. The implied usage is clear, but no explicit comparison or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare open-world and destructive hints, and the description adds 'Write, confirmation-gated,' which clarifies that this is a mutable operation requiring user confirmation. It also explains the splitting cadence, going beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose, and includes the essential mechanism and safety gate. Every word earns its place, with no redundancy or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex write operation, the description covers the core algorithm and safety (confirmation-gated), but it omits prerequisites such as token approvals or active wallet, and it does not describe the return value or post-order workflow. These gaps matter given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds relational meaning by explaining that fromAmount is split into equal chunks executed at regular intervals, which clarifies the interplay between fromAmount, chunks, and fillDelay beyond their individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb (Place), the resource (TWAP order via Spot protocol), and the mechanism (splits amount into equal chunks). This distinguishes it from sibling order types like 'orbs_place_limit' and 'orbs_place_order' by specifying the TWAP strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for time-weighted average price execution by describing the splitting behavior, but it does not explicitly state when to prefer this tool over alternatives like 'orbs_swap' or 'orbs_place_limit'. There is no when-not-to-use guidance or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the agent knows it is a state-changing operation. The description adds that the order must be externally signed and that inputs come from the prepare step, providing useful context. However, it does not disclose potential side effects, failure modes, or what happens after submission, which would add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, then provides the key source of inputs. It contains no filler or redundant information, earning its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter action with no output schema, the description conveys the essential usage (pre-requisite prepare step, external signature) but lacks information about the response, follow-up actions (e.g., checking order status via orbs_swap_status), or any post-submission behavior. It is adequate for selection but not fully complete for a complex financial action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving basic descriptions for all three parameters. The tool description adds cross-tool context by stating that submitUrl and order come from orbs_prepare_order_intent, which clarifies their origin and relationship beyond the raw schema. It does not add details about the signature parameter, but the schema already explains it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Submit' and the resource 'externally signed Spot order', clearly distinguishing this from sibling tools like orbs_place_order or orbs_submit_signed_swap by mentioning the external signature and the specific prepare step. It effectively identifies the tool's unique role in the order lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this tool is used after orbs_prepare_order_intent, giving clear context for when to invoke it. However, it does not explicitly exclude alternatives or explain when not to use it (e.g., if the order is not externally signed), so it falls slightly short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=true and destructiveHint=true, so the description doesn't need to restate that this is a state-changing operation. The description adds the nuance that the swap is externally signed, which affects the signing workflow, but doesn't disclose other behaviors like gas requirements, failure modes, or post-submission effects. This is moderate added value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action ('Submit') and then states the object and prerequisite. Every word contributes meaning, with no redundancy or filler. It is concise and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sparse for a complex operation. It references the quote from orbs_prepare_swap_intent and the external signing, but omits important workflow steps (e.g., how to obtain the signature, what happens after submission, potential return values). With no output schema, the agent is left without explicit information about expected results. The annotations and schema fill some gaps, but overall the description alone is not fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds semantic value by linking the 'quote' parameter to its source (orbs_prepare_swap_intent), clarifying the expected origin and format beyond the schema's generic 'Quote object from orbs_get_quote'. It also implicitly connects the 'signature' parameter to the external signing context. This extra context earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Submit an externally signed Orbs Liquidity Hub swap using the quote returned by orbs_prepare_swap_intent.' It uses a specific verb ('Submit'), identifies the resource ('externally signed Orbs Liquidity Hub swap'), and distinguishes itself from siblings by referencing the prerequisite quote from a specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow context by specifying the quote must come from orbs_prepare_swap_intent, implying a preceding step. It does not explicitly list alternatives or exclusions (e.g., when to use orbs_swap instead), but the 'externally signed' phrase hints at the distinction. Overall, it gives enough context for an agent to understand the typical usage flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only' and explains that policy limits are set by the user, not the agent. This adds context beyond the annotation, clarifying that the agent cannot modify limits and that the tool only reads. The description also discloses the specific types of data returned, which is helpful for setting expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, concise and front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second explains what it shows, and the third clarifies read-only behavior and who sets limits. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description adequately explains the return content (caps and remaining budget). The read-only nature and user-controlled limits are also covered. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter (includeRecentSpends) with its meaning and default. The description does not add any additional parameter-specific detail beyond what the schema already provides. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('current treasury policy limits and spend totals'). It further details the specific output (per-transaction, hourly, daily caps, budget remaining), making it distinct from any sibling tool, none of which relate to treasury policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking treasury policy and remaining budget, but does not explicitly state when to use it versus alternatives. It mentions that policy limits are user-set, which is more of a behavioral caveat than usage guidance. No alternatives are referenced, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the content of the inspection (methods, market types, timeframes, etc.) and the rationale (safe routing), without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and lists the key outputs. Every phrase contributes to understanding the tool's purpose and scope, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a discovery tool with no output schema, the description adequately covers what it does and why. It could be slightly more detailed about the return format or the requirement for at least one of exchange/account, but the schema covers the latter, and the overall context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters described. The description adds only a hint that 'exchange' or 'account' are alternative targets, but does not provide extra semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Inspect' and identifies the resource (CCXT exchange or configured account). It enumerates exactly what is returned (supported methods, market types, timeframes, symbols, invocation modes) and the purpose (safe request routing), distinguishing it from sibling call tools like ccxt_public_call and ccxt_private_write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so callers can route requests safely' clearly implies this tool should be used before making other CCXT calls to discover capabilities. However, it does not explicitly name alternative tools (e.g., ccxt_list_exchanges) or state when not to use it, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly, idempotent, and non-destructive annotations, the description adds valuable behavioral context: it returns only redacted metadata and guarantees secrets are never returned. This clarifies what data is exposed, which is crucial for a config-related tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tightly worded two-sentence summary that leads with the core action and adds a critical safety guarantee. Every word contributes meaningful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and rich annotations, the description covers the key aspects: the data source (CCXT_CONFIG_PATH) and the redaction policy. It does not detail the exact metadata fields returned, but this is adequately handled given the tool's simplicity and sibling tools for deeper exchange details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input surface. The description correctly focuses on output behavior rather than repeating schema details, and it adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured CCXT accounts from CCXT_CONFIG_PATH, with a specific verb ('List') and resource ('CCXT accounts'). It is distinct from sibling tools like ccxt_list_exchanges and ccxt_describe_exchange by naming 'accounts' explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for listing configured accounts but does not explicitly state when to use this tool versus alternatives like ccxt_private_read or ccxt_list_exchanges. It provides context (CCXT_CONFIG_PATH) but no direct guidance on selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, and idempotent behavior, lowering the bar. The description adds valuable context beyond these annotations by specifying the scope of included operations and mentioning 'authenticated read-only', which clarifies the security context. It doesn't describe deeper behaviors like rate limits or error handling, but given the annotations, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence earns its place. It is concise, clearly structured, and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, authenticated, no output schema), the description provides a clear conceptual overview and scope. It explains what types of methods are covered and confirms the read-only nature. It doesn't describe return values, but as a generic CCXT invoker, the return structure is method-dependent and not required for selection. The description is sufficiently complete for an agent to choose and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already thoroughly documents all six parameters (account, method, args, params, loadMarkets, reloadMarkets). The description adds no additional parameter-level meaning beyond what the schema provides, thus meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Invoke an authenticated read-only CCXT method using a configured named account.' It specifies the verb (invoke), resource (CCXT method), and distinguishes it from sibling tools like ccxt_public_call and ccxt_private_write by emphasizing 'private read-only' and listing covered data types (balances, positions, orders, fills).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by listing what it covers ('balances, positions, orders, fills, and private implicit GET-style endpoints'), implicitly differentiating it from public and write counterparts. However, it does not explicitly name alternatives or state when not to use this tool, falling just short of full guideline clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the 'at least one parameter' constraint but does not describe return format or error behavior, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste, front-loaded with the core action. Every word contributes to understanding the purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with annotations, the description is adequate. It does not describe the returned agent identity structure, but given the schema coverage and tool simplicity, the missing output details are not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with individual descriptions, but the description adds the critical XOR relationship between agentId and walletAddress, and clarifies that at least one is required—information not present in the schema's optional parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get ERC-8004 agent identity', a specific verb and resource. It distinguishes from sibling tools like erc8004_register_agent and erc8004_update_agent by focusing on retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear invocation context by requiring either agentId or walletAddress, with 'provide at least one' as an explicit usage instruction. It does not explicitly list alternatives, but the sibling names make the scope evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description adds meaningful side-effect context: it will perform an allowance check and possibly execute an approve transaction before funding, all in a single confirmation flow. This goes beyond the annotation's general danger flag and helps the agent anticipate the sequence of on-chain actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core purpose. It wastes no words and efficiently conveys both the action and the internal flow. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive write tool with no output schema, the description adequately captures what it does, the side-effect (approve), and the confirmation requirement. It does not explicitly state return values, but that is not required without an output schema. The surrounding sibling tools provide lifecycle context, making the description sufficiently complete for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (jobId, chainId, expectedBudget) with 100% coverage, so the baseline is 3. The tool description itself adds no parameter-specific meaning; it only says 'expected budget amount in token smallest units' in the schema, which is sufficient but minimal. No extra semantic value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Fund ERC-8183 job escrow.' It further distinguishes it from sibling tools by detailing the internal flow (allowance check + approve if needed, then fund), which uniquely identifies this as the funding operation in the ERC-8183 lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is the funding step in an escrow job lifecycle and mentions the allowance/approve flow, giving context for when to use it. However, it does not explicitly name alternatives or say when not to use it, though the sibling tool names (e.g., erc8183_create_job, erc8183_set_budget) provide enough distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: it can auto-resolve ABI from Etherscan and accepts abiLabel or abiJson as alternatives. This discloses the external dependency on Etherscan and the flexibility of input methods, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose ('Read contract state by function name') before detailing ABI options. Every word earns its place, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with full schema coverage and a readOnlyHint annotation, the description is adequately complete. It covers the core action and the main input variations. It could mention that the function must be a view/pure function, but this is implied by 'read' and the readOnlyHint annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (100%), but the description adds semantic relationships: it explains that abiLabel, abiJson, and auto-resolution are three alternative ways to provide the ABI. This contextual linkage is not apparent from the schema alone, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read contract state by function name.' This is a specific verb+resource pattern that distinguishes it from write operations (evm_write_contract) and ABI-fetching tools (evm_get_contract_abi). The mention of ABI resolution methods further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context on how to invoke the tool (provide abiLabel, abiJson, or auto-resolve from Etherscan) but does not explicitly state when to use it versus alternatives like evm_get_balance or evm_call. Usage is implied by the tool name and description, but no exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, establishing safety. The description adds behavioral context by noting that transfers from both ERC-721 and ERC-1155 are 'merged and sorted by time', which is valuable beyond the annotations. It does not contradict annotations, so a score of 4 reflects the additive value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the tool's purpose and key characteristics, with zero redundancy. It is well-structured and front-loaded, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers parameters and annotations cover the read-only/open-world behavior, the description provides sufficient context for tool selection. It explains the merging and sorting behavior, which is important. The absence of an output schema is mitigated by the straightforward nature of the tool, so a score of 4 reflects that it is near-complete without needing to describe return formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 seven parameters. The description does not add parameter-level information beyond the schema; it only refers to 'an address' which maps to the 'address' parameter. Baseline of 3 is appropriate as the description provides no extra semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'NFT transfer history', and specifies both ERC-721 and ERC-1155 for an address. It distinguishes from related tools like explorer_get_token_transfers (ERC-20) and explorer_get_nft_inventory (NFT ownership) by specifying 'transfer history' and the token standards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for retrieving NFT transfer history for an address, with no ambiguity. It does not explicitly mention alternatives or exclusions, but the inclusion of token standards effectively implies when to use this tool (for NFT transfers) versus other transfer/list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint and openWorldHint. The description adds valuable context by specifying that this is a write operation requiring wallet and confirmation, and by pointing out the need for token addresses. This goes beyond what annotations provide, though it doesn't detail failure modes or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word earns its place. It efficiently conveys the operation type, prerequisites, and safety requirements without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bridge execution tool with a destructive nature, the description covers key prerequisites (wallet, confirmation, token addresses). It doesn't mention the need for a prior quote or prepared intent, which are present in sibling tools, but the core requirements are stated. No output schema exists, so return-value details are not expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described as a token address or chain ID. The description's note about 'Requires token addresses' is somewhat redundant with the schema, and it doesn't add deeper semantic meaning to the parameters beyond what is already present. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute a cross-chain bridge' with a specific verb and resource. It distinguishes itself from sibling tools like lifi_get_quote and lifi_prepare_bridge_intent by framing itself as the execution step, and the 'write operation' note further differentiates it from read-only tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it requires a wallet and confirmation, and explicitly directs users to use resolve_token first to obtain token addresses. While it doesn't explicitly name lifi_get_quote or lifi_prepare_bridge_intent as prerequisites, the implication of sequencing is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds useful return-shape context ('symbol, address, decimals, and name') and specifies the static registry scope. It does not explain behavior for unsupported chains, but this is minor for a simple read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly worded sentences. The first states the action and scope, the second lists the exact return fields. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only list tool with no output schema, the description is sufficient: it names the registry, the chain scoping, and the return fields. It doesn't discuss unsupported-chain errors, but that is acceptable given the low complexity and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the only parameter, chainId, is fully documented as 'EVM chain ID'. The description adds no new parameter semantics beyond pointing to 'a specific chain', so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all well-known tokens in the built-in registry for a specific chain'). This clearly distinguishes it from broader market/explorer token tools, which focus on prices, balances, or on-chain data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use when you need the canonical well-known token list from the built-in registry for a specific EVM chain. It does not explicitly name alternatives or exclusions, but the 'built-in registry' scoping makes the intended use apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about the data source (DefiLlama) and return format (list of date/TVL pairs), which goes beyond the annotations and helps the agent understand what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and contains no redundant or filler words. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and strong annotations, the description adequately covers the return format and purpose. It does not mention units (e.g., USD), but this is a minor omission for a straightforward read-only TVL endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'chain' parameter, with an example provided in the schema. The description does not add additional parameter semantics beyond what the schema already states, but it also does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve', the resource 'historical TVL time series for a specific blockchain network', and the source 'DefiLlama'. It specifies the output as date/TVL pairs, which distinguishes it from related tools like market_get_protocol_tvl and market_get_token_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for chain-level historical TVL data, which is clear from the wording. It does not explicitly name alternative tools or when-not-to-use scenarios, but the context is unambiguous enough for an agent to select this tool for chain TVL history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds useful behavioral details beyond the annotations: it returns separate lists for gainers/losers, includes token symbol and price change percentage, and specifies the data source (DefiLlama).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, densely informative sentence. It front-loads the action and resource, then details the output structure without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only data retrieval tool with no output schema, the description adequately covers the return format and data source. It does not mention default values or edge cases, but the schema covers the period default, making the overall package sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive parameter names and enums for period. The description adds only minor context (e.g., 'specified time period') but does not meaningfully enrich parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving top gaining and losing tokens over a specified time period from DefiLlama. It specifies the output as separate lists with token symbol and price change percentage, distinguishing it from sibling market tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need top gainers/losers over a time period. It does not explicitly mention alternatives or exclusions, but the context is unmistakable and avoids ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm a safe, read-only, idempotent operation. The description adds meaningful, non-redundant context by naming the external data source (DefiLlama) and detailing the exact return fields (name, symbol, supply, peg type, mechanism). It does not cover pagination or default chain behavior, but these are less critical given the strong annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the verb and resource, with no redundant or extraneous information. Every sentence contributes to understanding the tool's function and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the tool's purpose, data source, and return structure, while the schema handles the optional chain parameter. It could mention how the chain filter behaves when omitted, but given the tool's simplicity and strong annotations, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the only parameter 'chain' with 'Filter by chain name', providing 100% coverage. The tool description adds no new information about this parameter, so it relies entirely on the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' with a clearly defined resource 'stablecoin market statistics' and elaborates on the data included, such as circulating supply and peg data, plus the return structure. This makes it unambiguous and distinguishes it from other market tools like token price or DEX volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context as a stablecoin-specific market statistics tool, implying when it should be used. However, it does not explicitly mention alternative tools or when not to use it, relying on the tool name and sibling list for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds context beyond that by specifying the data source (CoinGecko), the need for a coin ID, and the exact return data types (OHLC, market cap/volume). This provides useful operational context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main verb and resource, no fluff. Every word adds value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 params, no output schema), the description adequately explains the return data types and data source. It could specify the output structure (e.g., array of objects) but is otherwise complete for an agent to select and invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with detailed descriptions (token ID/address format, period enum). The description adds little beyond what the schema provides, only reinforcing 'by its coin ID' and 'specified number of days.' Baseline 3 is appropriate since schema does heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches historical price data for a token from CoinGecko, using a coin ID, and specifies the return types (OHLC candlesticks, market cap/volume). This is a specific verb+resource and distinguishes it from siblings like market_get_token_price (current price) and market_get_klines (exchange klines) by naming the CoinGecko source and including market cap/volume history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need historical price data for a token from CoinGecko, with details on input (coin ID/address) and output. However, it does not explicitly mention alternatives or when-not-to-use, so it falls short of a 5 but is still a useful usage guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior, so the description doesn't need to restate those. It adds value by specifying the data source (CoinGecko) and enumerating the return fields, giving the agent a clear expectation of the output. It doesn't mention rate limits or data freshness, but for a simple read-only list tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant information. It front-loads the primary action and then lists the output fields efficiently, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, full schema descriptions, and strong annotations, the description is largely complete. It covers the tool's purpose and return fields, while the schema handles parameter details. A minor gap is not describing the effect of the 'order' or 'category' parameters in prose, but this is acceptable since they are documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters (limit, order, category) have full descriptions in the schema, so the baseline is 3. The description itself does not add any parameter-specific semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves top cryptocurrencies by market capitalization from CoinGecko, with a specific verb ('Retrieve') and resource ('top cryptocurrencies'). It lists the returned fields, making its purpose distinct from siblings like market_get_top_protocols or market_get_token_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: whenever a list of top cryptocurrencies by market cap is needed. It doesn't explicitly mention alternatives or exclusions, but the clarity of the purpose avoids ambiguity. It could be improved by noting not to use it for single-token queries or protocol data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint: true and openWorldHint: true. The description adds valuable context beyond this: 'confirmation-gated' explains the confirmation requirement, and 'calling RePermit.cancel' clarifies the onchain mechanism. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence plus a short phrase 'Write, confirmation-gated.' Every piece of information is essential and front-loaded, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description provides the core action, mechanism, and confirmation gate. It lacks explicit return-value details, but the context is otherwise clear given the simple parameter set and sibling tools like orbs_swap_status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for both parameters (digest and chainId). The tool description does not add extra parameter meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Cancel a Spot order onchain by calling RePermit.cancel with the order digest.' This uses a specific verb (Cancel) with a resource (Spot order) and mechanism (RePermit.cancel with digest), fully distinguishing it from sibling tools like orbs_place_order or orbs_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to cancel a spot order) and adds context with 'Write, confirmation-gated,' indicating it's a write operation requiring confirmation. It doesn't explicitly name alternatives or exclusions, but sibling list shows no other cancel tool, so clear context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the prerequisite that token addresses are needed and directs users to resolve_token, which is useful behavioral context beyond annotations. It doesn't disclose internal API behavior or error conditions, but with strong annotations this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences. The first sentence states the core function, and the second sentence provides a critical prerequisite. There is no fluff or redundant information, and it is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description covers the essential context: what it does, the same-chain scope, and the prerequisite. It could mention what the quote contains or that slippage applies, but the schema covers slippagePct and the purpose is well-understood. It's fairly complete for a quote tool with strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter coverage with descriptions for all fields. The description reinforces that fromToken/toToken are token addresses and that the swap is same-chain, but it doesn't add new meaning beyond the schema, which already documents units, slippage, and defaults. A baseline of 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a quote from Orbs Liquidity Hub for same-chain aggregated swap.' It uses a specific verb ('Get a quote'), names the resource, and defines the scope ('same-chain aggregated swap'), which distinguishes it from sibling tools like lifi_get_quote (bridge quotes) and orbs_swap (actual execution).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it's for same-chain aggregated swaps and requires token addresses, with an explicit prerequisite to use resolve_token first. However, it does not explicitly state when not to use this tool or compare it to alternatives such as lifi_get_quote, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, covering safety. The description adds valuable context about what is checked (native asset wrapping and Permit2 approval) and when to use it (pre-signing), which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately communicates the tool's purpose and usage context. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a read-only pre-check), the annotations, and the schema's full parameter descriptions, the description is largely complete. It clearly explains the objective and timing, though it could optionally hint at the return format (e.g., list of required approvals) to fully close the loop.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 6 parameters, so the description does not need to add parameter-level details. The baseline of 3 is appropriate because the description adds no extra meaning beyond the schema, though it does contextualize the mode parameter via the 'Permit2' and 'RePermit' hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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'), a specific resource ('wrapping native assets or approving Permit2'), and a clear scope ('before signing an Orbs swap intent'). It distinguishes itself from sibling Orbs tools like orbs_get_quote or orbs_prepare_swap_intent by focusing on approval requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('before signing an Orbs swap intent'), providing clear context. However, it does not explicitly name alternative tools or state when not to use it, leaving room for clearer guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and open-world, and the description adds that it returns EIP-712 data and approval calldata, indicating no on-chain submission. This goes beyond the annotations by clarifying the tool's role in a signing workflow. However, it could disclose prerequisites like chain ID requirements or the need for an existing wallet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and immediately followed by the key return types. Every word earns its place, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately specifies the return categories, which is essential for the agent. It does not explain the subsequent signing or submission steps, but that is beyond the tool's direct scope. The required parameters are fully documented in the schema, making the description sufficient for a qualified agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 9 parameters, so the description adds no additional parameter-level meaning. The baseline of 3 applies 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as preparing a TWAP order for external wallet signing, with specific return values (EIP-712 typed data, approval calldata, metadata). This distinguishes it from execution tools like orbs_place_twap and other prepare tools like orbs_prepare_swap_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for external wallet signing' provides clear context for when to use the tool: to generate signing data rather than execute a trade. It does not explicitly name alternatives or exclusions, but the purpose is evident. A score of 4 reflects clear context without explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, so the safety profile is clear. The description adds value by disclosing the fallback to SDK query if the API is unavailable – a behavioral detail not captured in annotations. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose. Every word contributes meaning, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward read-only query with well-documented parameters and no output schema. The description covers the purpose, filters, and fallback. However, it does not describe the return format or any pagination, which would be useful since there's no output schema. Still, for a simple query tool with readOnlyHint, it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (hash, chainId, swapper) having its own description. The tool description merely restates the swapper and hash filters without adding extra meaning or clarifying chainId's default behavior beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query Spot orders by swapper address or order hash' – a specific verb (Query) + resource (Spot orders) with explicit filter criteria. It distinguishes itself from sibling order tools like orbs_cancel_order or orbs_place_order by being a read-only lookup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying existing orders and adds a fallback behavior ('Falls back to SDK query if Spot API unavailable'), which helps agents decide when to rely on it. However, it doesn't explicitly exclude alternatives or state when to prefer this over other order tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, open-world, idempotent, and non-destructive. The description complements these with the return fields (name, protocol, eligibility criteria, estimated value, claim deadline, status) and the data source (DefiLlama), adding value beyond the annotations. It also conveys urgency with 'before they expire,' which is useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences: the first states the core purpose, the second lists return fields and intended use. Every sentence earns its place, with no filler or redundancy, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema) and robust annotations, the description adequately covers purpose, return content, and urgency. It could be more complete by noting result sorting or default limits, but for a discovery tool, it provides enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'limit,' is fully described in the schema as 'Maximum number of results to return.' The description adds no additional meaning about how limit interacts with results, so with 100% schema coverage, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Discover active and upcoming token airdrop opportunities tracked by DefiLlama,' a specific verb-resource pairing that clearly identifies the tool's function. It distinguishes itself from sibling research tools by focusing solely on airdrops, a unique domain in the toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to help users identify and act on airdrop opportunities before they expire' provides clear context for when to use the tool, emphasizing time-sensitive discovery. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that results are sorted by APY and include TVL and protocol information, providing useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the core purpose, the second explains the output and value. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently describes the return: matching pools sorted by APY, including TVL and protocol info. It covers the essential output for a comparative yield tool and is complete for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full description coverage for all three parameters (token, limit, chainId). The description does not add additional parameter-level detail, but the schema already explains each parameter well, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares yield opportunities for a specific token across multiple protocols and chains, with output sorted by APY. This is a specific verb+resource combination that distinguishes it from sibling tools like research_yield_opportunities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: finding the highest yield for a given token across protocols and chains. It does not explicitly name alternatives or say when not to use, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond annotations by specifying it queries GoPlus Security and returns specific audit flags, giving the agent a good sense of behavior and data source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. It front-loads the primary action and output, with no redundant information. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with two parameters and no output schema, the description is adequate. It names the external service, lists example audit flags, and clearly indicates the input. It could mention chain support or output formatting, but those are secondary details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both address and chainId. The description adds no extra parameter details beyond what the schema already provides, so it earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Analyze' with a clear resource ('security posture of a smart contract'), and lists concrete outputs (honeypot detection, proxy patterns, etc.). It is clearly distinct from sibling research and explorer tools, which focus on other data points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear usage context: when you need a security audit of a contract address. However, it does not explicitly mention alternatives or when not to use it, though the research category context makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds behavioral context by specifying the data source (DefiLlama) and the exact return format (list of incidents with protocol name, date, USD amount, attack technique, source URL), which is valuable since no output schema is provided. Minor gaps remain regarding pagination or default sorting, but the description meaningfully supplements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one sentence, front-loaded with the action and resource, and every clause earns its place. It efficiently conveys purpose, return data, and use case with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple query tool with 2 optional parameters, no output schema, and strong annotations. The description covers the what, the data returned, and the intended use case. Minor omissions like default limit behavior or sort order are not critical given the simplicity and schema coverage, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'limit' and 'protocol' already described in the input schema. The description adds no parameter-specific details or examples. Baseline 3 is appropriate because the schema carries the full burden and does so adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Query the history of DeFi hacks and exploits tracked by DefiLlama') and resource, clearly distinguishing it from sibling research tools like research_contract_security or research_token_due_diligence. The listed return fields (protocol name, date, USD lost, attack technique, source URL) further solidify the tool's unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'enabling security research and risk assessment of protocols.' It does not explicitly name alternatives or exclusions, but the purpose is specific enough that usage is implied. Without a 'when not to use' note, it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations by specifying the data source (DefiLlama's large transactions feed) and the returned fields (sender, receiver, USD amount, etc.), filling in behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, dense sentence that front-loads the core purpose and packs in useful details without any filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool, the description covers purpose, data source, and return fields adequately. Minor details like default limit or pagination behavior are absent, but these are not critical for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (limit and symbol) have descriptions in the schema, giving 100% schema coverage. The description does not add extra parameter-level details beyond what the schema already states, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool tracks large on-chain token transfers (whale movements) using DefiLlama's feed, with a specific verb and resource. It distinguishes itself from generic transfer tools like explorer_get_token_transfers by focusing on high-value transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use: to monitor smart money flows and potential market-moving activity. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation, and the description adds useful context by listing the specific status data returned. It does not contradict the annotation and provides beyond-annotation detail about the contents of the status report.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose and the key return fields. No wasted words or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 must carry the burden of explaining what is returned. It lists the main status categories, which is adequate for a simple status query, though it could be more specific about possible values (e.g., wallet mode states).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies per the rubric. The description correctly omits parameter details because there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('server status'), and names the exact fields returned (wallet mode, active chain, confirmation setting, backend health). This clearly distinguishes it from the many market, research, and explorer sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is given. The intended usage is implied by the tool's name and description, but the description does not state when this tool should be preferred over others or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation marks destructiveHint=true, but the description adds meaningful context beyond that: it explains backend selection (encrypted OWS vault vs. legacy storage), the emission of wallet-changed, and the secret gating via WEB3AGENT_ALLOW_AGENT_VISIBLE_SECRETS. These are behavioral traits not present in the annotations, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action and backend selection, followed by the event emission, security gating, and CLI preference. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 optional params, no output schema, only destructiveHint annotation), the description covers the key contextual aspects: backend selection, side-effect event, secret gating, and a local CLI alternative. It doesn't explicitly state success return values, but the wallet-changed event signals outcome, so this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of parameter descriptions (mnemonic, privateKey, accountIndex, addressIndex). The description reinforces that a private key or mnemonic is used but doesn't add new semantic detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Activate a wallet from a private key or mnemonic using the selected backend.' It specifies the resource (wallet), inputs (private key or mnemonic), and distinguishes itself from sibling tools like wallet_deactivate and wallet_delete by focusing on activation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context on when to use the tool and when to avoid it: 'Prefer local CLI: npx web3agent wallet activate' clearly points to an alternative. It also notes the environment variable requirement when secrets are provided, which helps the agent decide whether to invoke this tool. However, it doesn't explicitly state 'do not use this tool in X scenario' beyond the CLI preference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds important behavioral context: the tool requires a specific environment variable (WEB3AGENT_ALLOW_AGENT_VISIBLE_SECRETS=1) because it handles a mnemonic in agent context, and it discloses the output fields. This goes beyond the annotation by explaining the gating and security-sensitive nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences: purpose, output, and gating/alternative. All sentences earn their place, are front-loaded with the core function, and contain no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of a complete input schema, the description is adequately complete. It summarizes output, notes the read-only nature via annotations, and discloses the gating requirement. It lacks a full output schema, but the summary of return fields is sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters (mnemonic and count) with descriptions including the default and range. The tool description adds no further parameter-specific details beyond what the schema provides, so it stays at the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('derive') and resource ('addresses from a mnemonic'), with a count range (1-20). It distinguishes itself from related wallet tools by emphasizing 'multiple addresses' and specifying the output (index, address, derivation path), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is gated behind an environment variable, and the instruction 'Prefer local CLI' signals when not to use this tool in favor of a local alternative. It does not explicitly name sibling tools like wallet_from_mnemonic, but the gating and CLI preference give actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a non-mutating operation, and the description adds valuable context by stating it does not expose secrets. It also discloses that the tool covers storage security posture and current wallet state, giving a clearer behavioral profile than the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose and includes a meaningful caveat. Every element contributes value with no redundancy or filler, achieving high conciseness for a zero-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and a readOnlyHint annotation, the description provides a complete high-level overview of what the tool returns (metadata, security posture, state). It could mention whether an active wallet is required or how the output is structured, but for this simple tool, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to clarify about parameters. Per the calibration baseline, a tool with 0 parameters earns a 4. The description adds no parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('wallet backend metadata, storage security posture, and current wallet state'). It also adds a scope restriction ('without exposing secrets'), which distinguishes it from wallet action tools like wallet_activate or wallet_delete. The purpose is unambiguous and well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to retrieve wallet information, but it does not explicitly state when to use it over similar wallet-related tools like wallet_get_active or evm_get_balance. There are no exclusions or named alternatives, so the guidance is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is known. The description adds value by disclosing the result contents ('agent profiles with capabilities, metrics, and available services'), which helps an agent understand what to expect after invocation. It does not detail sorting or ranking, but given the annotation coverage, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise, front-loaded sentences. The first states the main action and destination, the second the return value. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two optional parameters, read-only annotations, no output schema), the description is complete: it states what the tool does, where it searches, and what it returns. The schema covers parameter details, and the annotations cover safety, so an agent has enough context to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters: 'topK' (max results, default 10) and 'query' (search query). The description does not add any parameter-specific meaning beyond what the schema already provides. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' followed by the resource 'aGDP marketplace', and clearly states the return value: 'agent profiles with capabilities, metrics, and available services'. This cleanly distinguishes it from sibling tools like agdp_get_offering (singular) and the broader market_* tools that cover crypto market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the tool to use for broad marketplace searches and what it returns. However, it does not explicitly mention when not to use it, such as when a specific offering ID is known (which would warrant agdp_get_offering), nor does it name any alternative tools. The context is clear but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read-only operation. The description adds value by specifying what is returned (address, mode, chain context), giving the agent more context about the tool's behavior beyond what the annotation provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It front-loads the action and clearly lists the output fields, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and a clear return value, the description is complete. The readOnlyHint annotation covers the safety aspect, and the description provides the essential information about what the tool retrieves. No further elaboration is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies per the rubric. No additional parameter explanation is needed. The description is sufficient to understand that no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the currently active wallet address, mode, and chain context. It uses a specific verb 'Get' and names the resource and the specific data returned, distinguishing it from sibling tools like get_address or wallet_get_active that may only return the address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving the active wallet context, but it does not explicitly state when to use it versus sibling tools like wallet_get_active or get_address. No exclusions or alternative guidance is provided, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers the safety profile. The description adds the nuance that the tool returns labels (not full ABIs) and that these are registered via evm_register_abi. However, it doesn't mention return format, ordering, or state scope, so it adds only a modest amount beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear verb and resource. It contains no filler or redundant information, front-loading the action ('List') and providing the exact scope ('all ABI labels registered via evm_register_abi').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only tool, the description is complete. It explains what is listed (ABI labels) and where they come from (via evm_register_abi). With no output schema, the description still implies the return type (a list of labels), which is sufficient for an agent to understand the tool's purpose and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, making schema coverage 100%. The baseline for 0 params is 4. The description adds no parameter info (there is none needed), but it does clarify that the output is a list of ABI labels, which is useful context for what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('ABI labels') with a clear source qualifier ('registered via evm_register_abi'). This distinctly separates it from sibling tools like evm_get_contract_abi (which retrieves a specific ABI) and evm_register_abi (which adds new ABIs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates that the tool lists all ABI labels registered via evm_register_abi, providing a clear context for when to use it. It doesn't explicitly name alternatives or exclusions, but the context makes it obvious that this is the tool for enumerating registered labels rather than retrieving a single ABI.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructive and open-world behavior. The description adds valuable context by explaining the amount is in smallest units and giving a concrete USDC example, which goes beyond what annotations provide. It also directs the user to check decimals, a key behavioral nuance. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action verb, and contains no filler. Every sentence contributes useful information: what it does, the unit nuance, and a practical tip.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is straightforward and schema/annotations cover parameters and safety, the absence of an output schema means the description should explain expected return values (e.g., transaction hash, receipt). It does not, nor does it mention what happens after broadcast or any other prerequisites, leaving a gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so a baseline of 3 applies. The description adds extra meaning by providing a real-world example and cross-referencing evm_get_token_balance, particularly enriching the 'amount' parameter's semantics beyond the schema's 'wei-equivalent' note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Transfer ERC-20 tokens' with a specific verb and resource. It distinguishes itself from sibling tools like evm_transfer_native by explicitly focusing on ERC-20 tokens. The added decimal example reinforces the tool's specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear prerequisite: 'Use evm_get_token_balance to check decimals first,' which guides the user on a necessary step. It implicitly indicates this is for ERC-20 transfers, but it does not explicitly name alternatives or state when not to use it. This is clear context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds value by specifying the return structure (category name, total market cap, 24h change, top-3 coins), which helps set expectations. It doesn't mention pagination or default limits, but for a read-only list endpoint with good annotations, this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence without unnecessary words. It front-loads the core action and resource, then lists the key return fields. Every element contributes to understanding the tool, making it excellent in conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-returning read-only tool with no output schema, the description provides sufficient completeness by enumerating the returned fields. Combined with full parameter schema coverage and strong annotations, it gives the agent everything needed to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'limit' and 'order' having clear descriptions. The tool description does not add parameter-level detail beyond what the schema provides, so it stays at the baseline of 3. It doesn't need to compensate for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('cryptocurrency categories from CoinGecko'), and the specific data returned (name, total market cap, 24h change, top-3 coins). This distinguishes it from sibling market tools that focus on protocols, TVL, tokens, or prices, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: whenever category-level market data is needed. It doesn't explicitly name alternatives or exclusions, but the specificity of 'categories' implicitly differentiates it from token/protocol tools. Slight lack of explicit 'use X instead' holds it back from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by noting the tool is deprecated and Binance-specific, and explains that it returns bid/ask levels with quantities up to the requested depth. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a deprecation notice, a clear function statement, and a return-value summary in just two sentences. All content is relevant and no filler is present, though the deprecation notice could be seen as redundant given the 'Deprecated' tag, but it's still useful context. Front-loading the deprecation is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with only two parameters, the description covers the essential context: purpose, exchange source, return content, and deprecation status. Annotations handle safety and idempotency. The lack of an output schema is mitigated by describing the return shape at a high level. However, it doesn't mention potential edge cases like invalid symbols or rate limits, but these are not critical for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both symbol and limit have descriptions in the schema. The description adds minimal extra meaning beyond that, only hinting at the limit's effect via 'up to the requested depth.' Since the schema fully documents parameters, the baseline 3 is appropriate; no significant additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool fetches the current order book depth for a trading pair from Binance, with a specific verb and resource. It distinguishes itself from sibling tools by focusing on Binance order book data, which none of the siblings cover. The deprecation note does not confuse the primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description opens with a clear deprecation warning and explicitly names ccxt_public_call and ccxt_describe_exchange as preferred alternatives for new integrations. This provides direct when-to-use guidance, though it doesn't elaborate on scenarios where the old tool might still be appropriate. The alternative naming is explicit and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only/idempotent. The description adds valuable behavioral detail by enumerating the return payload: current TVL in USD, 1d/7d/30d percentage changes, per-chain breakdown, category, and website URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, then efficiently lists all return fields. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one documented parameter and read-only annotations. The description lists key outputs, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter 'protocol' is well documented with examples. The description merely repeats 'DefiLlama slug' without adding new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('Total Value Locked for a specific DeFi protocol by its DefiLlama slug'). It distinguishes from siblings like market_get_top_protocols (which lists protocols) and market_get_chain_tvl (which fetches chain-level TVL).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use when you need TVL for a single protocol, identified by slug. Does not explicitly name alternatives or when-not-to-use, but the sibling list and the word 'specific' imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds useful behavioral context: it names DefiLlama as the oracle and lists return fields (price, symbol, decimals, confidence score, last-updated timestamp). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with no filler. The first sentence states the action and source; the second details input format and return fields. Highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (2 params, 1 required, no nested objects) and has no output schema, so the description appropriately covers return fields and input format. This provides sufficient context for an agent to invoke the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions already explain the format. The description adds an example ('ethereum:0x...') and clarifies the array semantics, but does not provide significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches current USD prices for one or more tokens using DefiLlama's price oracle. It distinguishes itself from sibling tools like market_get_token_history (historical prices) by specifying 'current' and the oracle source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (current prices, token identifiers in 'chain:address' format) and implies when to use it. It does not explicitly mention alternatives or exclusions, but it is not misleading and gives enough context for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/destructive false. Description adds data source (DefiLlama governance tracker) and return fields (title, status, votes, dates, links), but doesn't quantify 'recent' or mention pagination limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description enumerates all return fields. Parameters are all optional and schema-documented. Sufficient for a simple read-only filtered list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions (limit, status enum, protocol). Description doesn't add further parameter detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch active and recent governance proposals for DeFi protocols from DefiLlama's governance tracker'—specific verb, resource, and source, and lists return fields, distinguishing it from siblings like research_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context: the tool is for governance proposals, distinct from other research_* tools. No explicit exclusions or alternative recommendations, but the specific scope makes usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: the data source (DefiLlama's vesting tracker) and the specific return fields (next unlock date, USD value, current price, estimated price impact). This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and source, then lists return fields and use case. Every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description is complete. It states the source, the purpose, the exact return fields, and the use case. No critical operational details are missing given the low complexity and strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter ('limit' with description 'Maximum number of results to return'), giving 100% schema coverage. The description does not add any additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' with a clear resource: 'upcoming token unlock events from DefiLlama's vesting tracker.' It clearly distinguishes itself from sibling research tools like research_token_holders and research_token_due_diligence by focusing on unlock events and supply-side selling pressure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating it is 'useful for anticipating supply-side selling pressure.' It does not explicitly name alternatives or exclusion conditions, but the context is sufficient for a simple read tool among many research siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses automatic pruning of expired entries, adding useful behavioral context. It does not mention return format, but the annotation already covers safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action, no wasted words. Perfectly sized for the simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what is listed and the pruning behavior but lacks information on the return structure or how to use the results with confirmation/denial tools. Without an output schema, this leaves a gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers 100% of the parameter space. The description adds no parameter details, but none are needed, so baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' and resource 'all pending operations awaiting confirmation', clearly distinguishing from siblings like transaction_confirm and transaction_deny. It fully states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is given that this lists pending operations, implying use before confirmation/denial actions. However, it does not explicitly state when not to use it or name alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already declares this as a safe read operation, and the description is consistent, stating 'Get'. It adds the specific output fields including the mode enumeration (private-key, mnemonic, or read-only), which clarifies behavior. However, it does not disclose edge cases like behavior when no active wallet exists, though the low annotation bar makes this acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 18 words, front-loaded with the verb, and lists the three output items without waste. It effectively balances brevity with informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a readOnlyHint annotation, the description fully covers what the tool does and returns. It names all three data fields, making it sufficient for an agent to select and invoke the tool correctly. No further details are necessary for this simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and the description needs no parameter details. Per baseline for 0 params, this scores 4, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'the currently active wallet', listing the exact data returned (address, chain ID, mode). This clearly distinguishes it from siblings like wallet_activate (which activates) and wallet_info (likely broader info), giving a distinct, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the active wallet's address, chain, or mode is needed, but it does not provide explicit alternatives or exclusions. There is no mention of when to prefer this over wallet_info or evm_get_wallet_address, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by detailing the internal steps: checks payment cost, queues confirmation, executes, and no-ops if no payment is needed. This discloses important behavioral traits like potential user confirmation and side-effect-free execution when no payment is required, which annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with three short sentences that immediately state the core action ('Fetch a URL'), then efficiently explain the conditional payment behavior. Every sentence earns its place, and the structure is front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complex payment flow, the description covers the high-level steps but omits important context such as the return value format, potential failure modes (e.g., payment denied), and relationship with the sibling x402_check_requirements. Given the absence of an output schema, more detail would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter already has a meaningful description. The tool description does not add extra parameter semantics beyond what is in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Fetch a URL') and clearly distinguishes itself from the sibling x402_check_requirements by indicating that this tool actually fetches and can pay. The payment behavior is at the forefront, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when the tool is used (when a URL fetch may require payment) and describes the condition-based flow ('if required', 'if payment needed'). However, it does not explicitly mention alternatives or when not to use this tool, such as pointing to x402_check_requirements for checking payment requirements only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations (openWorldHint, destructiveHint) by disclosing that it automatically checks allowance, approves ERC-20 if needed, and creates a payable memo escrow. This informs the agent about side effects and state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action ('Fund a Virtuals ACPRouter job') and then efficiently packs essential behavioral details without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, side effects, and escrow creation, making the tool understandable. However, with no output schema, it does not mention the return value (e.g., transaction hash or job status), which is a useful detail for a funding operation. This is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all four parameters, including units for amount. The description adds no parameter-specific details but gives contextual background on the funding flow. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fund' with a clear resource 'Virtuals ACPRouter job' and outlines the process (checks allowance, approves ERC-20, creates escrow). This distinguishes it from similar sibling tools like erc8183_fund_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use this tool (to fund a Virtuals ACPRouter job) by naming the protocol and job type. However, it does not explicitly contrast with alternatives like erc8183_fund_job, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructive/open-world behavior, but the description adds valuable context: 'requires wallet and confirmation,' which is a significant behavioral trait beyond the annotations. No contradiction with annotations. However, it does not detail side effects or costs, though the added context is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, and no redundant information. The pointer to acp_create_job is concise and valuable, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides purpose, prerequisites, and an alternative, which is sufficient for a write operation with no output schema. It does not explain the return value or the structure of serviceRequirements, but those are not fully expected given the schema and sibling context. Overall, it is complete enough for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with descriptions for both parameters ('Agent ID to hire' and 'Service requirements'), so baseline is 3. The tool description itself adds no extra parameter meaning, and the schema descriptions are minimal, especially for serviceRequirements, which lacks structural detail. Still, the schema does carry the basic semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies the action (hire), the resource (AI agent), and the source (aGDP marketplace), with the verb 'hire' providing a specific operation. It also distinguishes from sibling tools by noting the alternative for on-chain job creation via acp_create_job, which helps differentiate this tool from related ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states an alternative: 'For on-chain job creation, use acp_create_job separately.' This provides clear when-not-to-use guidance. It also mentions prerequisites (wallet and confirmation), indicating the context under which this tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral limitation beyond the readOnlyHint: it explicitly excludes ERC-20 token balances, which is not implied by the annotation. It also confirms ENS name resolution for the address field, adding context. There is no contradiction with the readOnly/openWorld annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary purpose front-loaded and the key exclusion in the second sentence. Both sentences contribute essential information, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with annotations and full schema coverage, and the description covers purpose, input scope, and exclusions. The only notable gap is the lack of return format (e.g., wei vs. ether) in the absence of an output schema, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (address as 'Wallet address or ENS name', chainId as 'Chain ID (defaults to runtime config)'). The description merely reiterates the address/ENS part and adds nothing about chainId or value formats, so the baseline 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a precise verb and resource: 'Get NATIVE token balance' for an address or ENS name, and it explicitly distinguishes itself from ERC-20 balance queries by naming evm_get_token_balance. This satisfies both the specific-resource and sibling-differentiation criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not guidance: 'This does NOT return ERC-20 token balances — use evm_get_token_balance for that.' It also clarifies the intended input ('address or ENS name'), making it clear when this tool is appropriate versus its ERC-20 counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it notes the tool is 'Confirmation-gated' and explains ABI auto-resolution. This complements the destructiveHint: true annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, followed by key usage details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema description coverage and annotations indicating destructive behavior, the description adequately covers main contextual aspects: purpose, ABI resolution, and confirmation. It does not describe return values, but no output schema exists and the core behavior is sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema descriptions cover all parameters, the tool description adds meaning by explaining the relationship between abiLabel, abiJson, and auto-resolution. This clarifies the optionality and provenance of ABI-related parameters, supplementing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute a state-changing contract function'), specifying both the verb and resource. The tool name and 'state-changing' distinguish it from read-only siblings like evm_read_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to invoke the tool, including ABI resolution options ('Provide abiLabel (from evm_register_abi), abiJson, or let the tool auto-resolve') and mentions it is confirmation-gated. It does not explicitly name alternatives or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful context beyond annotations: it is deprecated, fetches from Binance, and returns specific OHLCV fields. It does not cover potential rate limits or error cases, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first delivers the deprecation warning and alternatives, the second states the core functionality and return values. Every word earns its place, and it is front-loaded with the most important usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and schema cover parameters and safety, the description is largely complete. It states what the tool returns (OHLCV fields) and the source (Binance), but does not describe error behavior or time-range semantics beyond 'requested range', which is slightly vague. Still, acceptable for a deprecated tool with clear alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant parameter-level detail beyond what the schema already provides (symbol, interval enum, limit). It mentions 'specified interval' and 'requested range', but these are already implicit in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches candlestick (OHLCV) chart data for a trading pair from Binance at a specified interval, and lists the returned fields. This specific verb+resource description distinguishes it from sibling market tools like ticker or order book.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly declares the tool deprecated and directs users to ccxt_public_call and ccxt_describe_exchange for new integrations. This provides clear when-to-use guidance and names alternatives, which is exactly what the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering side-effect safety. The description adds the return payload structure (required approvals, full quote, EIP-712 typed data) and the intent for external signing, which clarifies that the tool does not execute the swap or approvals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, front-loaded sentence: 'Prepare a same-chain Orbs swap intent for external wallet signing. Returns required approvals, full quote, and EIP-712 typed data.' No filler or gratuitous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a preparation tool with no output schema, the description covers purpose, return values, and usage context. It does not mention workflow steps (like submitting approvals before the signed swap), but the readOnly annotations and the 'prepare' verb mitigate any ambiguity. A small gap in explicit post-conditions prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds a key semantic constraint—'same-chain'—clarifying that fromToken and toToken must be on the same chain unless chainId overrides. It also indicates the inclusion of approval data in the output, which is not schema-explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'prepare' and identifies the resource as a 'same-chain Orbs swap intent.' It lists the outputs (required approvals, full quote, EIP-712 typed data) and the context (external signing), making it distinct from execution tools like orbs_swap and other intent types such as orbs_prepare_twap_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for external wallet signing' supplies clear context: use this tool when the swap must be signed by an external wallet rather than executed directly. No explicit alternatives or exclusions are named, but the context is enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag the tool as destructive; the description adds that it is 'confirmation-gated', meaning it will require user confirmation before execution. It also lists supported chains and notes the need for token addresses, which are important behavioral constraints. It does not detail post-confirmation steps or return values, but the addition of confirmation-gating goes beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the action and resource, followed by supported chains and a required prerequisite. Every sentence carries essential information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with five parameters and no output schema, the description covers the core purpose, supported chains, prerequisite token addresses, and confirmation-gated behavior. It lacks details about return values or the broader Orbs swap workflow, but the given information is sufficient for an agent to select and invoke the tool correctly. The schema and annotations fill in additional details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all five parameters with clear descriptions, achieving 100% coverage. The description adds meaningful context by stating that token addresses are required and pointing to resolve_token for obtaining them, which clarifies the expected format for fromToken and toToken. This elevates it above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a same-chain swap via Orbs Liquidity Hub' with a specific verb and resource. It distinguishes from sibling tools like orbs_place_twap or orbs_prepare_swap_intent by specifying same-chain swap and listing supported chains. The phrase 'write, confirmation-gated' also indicates the nature of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: for same-chain swaps on specific chains, with token addresses as input. It explicitly directs the user to 'use resolve_token first' to obtain token addresses, which is a valuable usage prerequisite. However, it does not explicitly name alternatives like orbs_place_twap for TWAP or lifi_execute_bridge for cross-chain, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include idempotentHint=true, which is sparse. The description adds valuable behavioral context: reverting to read-only ephemeral mode and explicitly preserving persisted wallet material. This clarifies the non-destructive nature and aligns with idempotency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant words. Every part adds value: action, target, mode change, and preservation of persisted material.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers the core action and the critical non-destructive behavior. It could briefly clarify the implications of 'read-only ephemeral mode', but the current level is sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description adds meaningful context by specifying 'current runtime/session wallet', which clarifies what the tool operates on, compensating for absence of schema guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Deactivate' and clearly identifies the resource as 'current runtime/session wallet'. It also states the outcome ('revert to read-only ephemeral mode') and explicitly what it does NOT do ('without deleting persisted wallet material'), which distinguishes it from wallet_delete and complements wallet_activate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to deactivate the active runtime/session wallet. It indirectly contrasts with deletion, but does not explicitly name alternatives like wallet_delete or wallet_activate, nor does it provide explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral context: it does NOT return the private key, and it requires a specific environment variable because the mnemonic is agent-visible. This meaningfully clarifies security-sensitive behavior and complements the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences deliver the core purpose, a critical limitation, and security gating. The description is front-loaded and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, limitations, and gating, which is strong given the readOnly annotation and simple parameter set. However, it does not specify the returned address format or the target chain/coin type, and there is no output schema to fill that gap, so a small amount of ambiguity remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents all parameters with names, types, defaults, and descriptions (100% coverage). The description only reiterates that account/address index are optional, adding no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Derive an address from a BIP-39 mnemonic at optional account/address index.' It also scopes the behavior by noting it does not return the private key and explicitly calls out the gating requirement, which helps distinguish it from related wallet tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical guidance: it requires WEB3AGENT_ALLOW_AGENT_VISIBLE_SECRETS=1 and advises 'Prefer local CLI.' While it doesn't name a specific alternative tool, the preference for local CLI and the explicit gating condition provide clear context for when this tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is true, and the description does not contradict it. The description adds the gating requirement and the fact that this tool exposes secrets (agent-visible secrets), which is beyond what the annotation provides. It also mentions the derived address, giving a hint of the return value. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, with two sentences that each earn their place: the first states the core purpose, the second provides critical usage context (gating and CLI alternative). No fluff or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 is sufficiently complete. It states what the tool generates, includes security-relevant gating info, and gives a recommended alternative. It doesn't explicitly describe the exact output format, but the phrase 'with its first derived address' gives a solid hint. Missing only explicit guidance on handling the sensitive mnemonic, but that's partially covered by the gating note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is effectively 100% and the description has no need to explain parameters. The baseline for 0 params is 4, and the description doesn't add any unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate a new BIP-39 mnemonic phrase with its first derived address.' This is a specific verb+resource pairing that distinguishes it from sibling tools like wallet_from_mnemonic (which derives from an existing mnemonic) and wallet_generate (which likely generates a different wallet object).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative: 'Prefer local CLI: npx web3agent wallet generate --mnemonic.' It also states the gating condition (requires WEB3AGENT_ALLOW_AGENT_VISIBLE_SECRETS=1), which gives clear context for when to use this tool. However, it doesn't explicitly say when not to use it beyond preferring the CLI, and it doesn't compare against sibling wallet tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, so the bar is lower. The description adds meaningful behavioral context: the tool is deprecated, real-time, Binance-specific, and lists the exact return fields. It does not cover rate limits or error behavior, but the deprecation warning is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each earning its place: deprecation warning, core action, and return summary. No fluff, front-loaded with the most important selection criterion (deprecation).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description fully covers the purpose, scope, and return contents. The deprecation guidance completes the picture for an agent deciding whether/where to use it. No additional context appears necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the one parameter 'symbol' is fully described in the schema with examples. The tool description does not add further parameter meaning beyond 'specified symbol', so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches real-time 24-hour ticker statistics for a trading pair from Binance, with a specific verb 'Fetch' and resource 'ticker statistics'. It distinguishes from sibling market tools (klines, order book, etc.) by specifying its exact scope and return fields. The deprecation notice does not obscure the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to prefer ccxt_public_call and ccxt_describe_exchange for new integrations, providing clear when-to-use versus when-to-avoid guidance. This is strong alternative naming and exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a state-changing, destructive operation. The description adds meaningful context: it is gasless, confirmation-gated, and order type is determined by parameters. This goes beyond the annotations and helps the agent anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and dense with information. It front-loads the primary purpose and then efficiently explains order-type determination. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 13-parameter tool, the description covers order type logic and confirmation behavior. It does not describe the response format or potential failure modes, but given the schema completeness and the fact that annotations cover safety profile, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant cross-parameter meaning by mapping parameter conditions to order types (e.g., outputLimit > 0 for limit, fromMaxAmount > fromAmount + epoch for TWAP). This synthesis is not apparent from individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places a gasless order via Spot protocol, listing supported order types. It distinguishes itself from specialized siblings like orbs_place_twap and orbs_place_limit by presenting itself as the general-purpose order tool with parameter-driven order type selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining how to configure each order type through parameter combinations. It does not explicitly contrast with sibling tools or state when to prefer this over specialized versions, but the parameter guidance effectively tells the agent how to use the tool for various scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool uses a built-in registry with a DexScreener fallback, which is extra context beyond the readOnlyHint and openWorldHint annotations. It implies that for non-major tokens, results may rely on the fallback. This adds meaningful behavioral insight, though it doesn't fully describe return format or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a purpose: stating the action, explaining the mechanism, and giving usage guidance. No redundant text; it is concise, well-structured, and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only resolver, the description is thorough. It explains what the tool does, how it works (registry with fallback), and when to use it. While there is no output schema, the description implies the return includes address and decimals. This is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters completely (100% coverage) with descriptive text and examples for symbol and chainId. The description adds examples and clarifies the output (contract address and decimals), but doesn't significantly enhance parameter understanding beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Resolve a token symbol to its contract address and decimals on a specific chain.' It provides concrete examples (USDT, WBNB) and differentiates from sibling tools by explicitly naming alternatives to avoid. The verb 'resolve' and resource are specific and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'ALWAYS call this first when you need a token address' and directly instructs not to use similar tools like blockscout_lookup_token_by_symbol or get_token_info_by_symbol. This clearly establishes when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the destructiveHint annotation: 'Permanently delete' specifies irreversibility, 'requires explicit confirmation' warns about the confirmation requirement, and 'revert to read-only ephemeral mode' discloses the post-condition. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using two sentences to convey the action, scope, destructive consequence, and confirmation requirement. Every word adds value, and the warning is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, destructive tool with no output schema, the description fully covers the purpose, consequences, and prerequisites. It also distinguishes itself from the many sibling wallet tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage (empty schema), the description has no parameter details to add. The baseline of 4 applies, and the description appropriately focuses on behavior rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('delete') and resource ('persisted wallet material'), and distinguishes it from siblings like wallet_activate and wallet_deactivate by noting the permanent, destructive nature and the resulting revert to ephemeral mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly defines when to use this tool (when permanent deletion is required) and indicates the consequence (revert to read-only ephemeral mode). It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to differentiate from temporary deactivation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction. The description adds useful behavioral context by disclosing the return payload (payment requirements: amount, network, token) and that it confirms when no payment is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, no filler or redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has read-only annotation, and the description clearly states what it returns. No output schema is needed because the description covers return values. The description is complete for this pre-flight check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all three parameters. The description does not add extra parameter semantics beyond stating the primary url parameter purpose, which is already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks if a URL requires x402 payment, with a specific verb and resource. It distinguishes from the sibling x402_fetch by explicitly mentioning its purpose as a pre-fetch cost preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use before x402_fetch to preview costs, providing clear context and naming the alternative tool. This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only/idempotent/non-destructive behavior, so the bar is lower. The description adds valuable behavioral context: it returns funding rate, time, and mark price, and notes the data source (Binance). It also signals deprecation, which is important for an agent weighing tool choice. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the deprecation warning, and every sentence provides distinct value: deprecation guidance, functional description, return fields, and use case. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with annotations and full schema, the description is almost complete. It explains the purpose, return fields, and deprecation alternatives. The only gap is the ambiguity of 'one or all symbols' given that the schema marks 'symbol' as required, plus the behavior of 'limit' in relation to 'current' rates is not fully clarified. Still, it is functionally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both symbol and limit have descriptions), so baseline is 3. The description adds meaning to 'symbol' by saying 'one or all symbols', which goes beyond the schema's example-based description. It does not add detail on 'limit' beyond the schema, but the extra symbol semantics justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches current perpetual futures funding rates from Binance, specifying the resource (funding rates) and scope (one or all symbols). It distinguishes itself from sibling market tools by naming specific return fields (funding rate, funding time, mark price) and the exchange source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Deprecated: prefer ccxt_public_call and ccxt_describe_exchange for new integrations', giving clear when-not-to-use guidance and naming alternatives. It also provides a use case ('tracking carry costs in leveraged positions'), so usage context is well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint is supplemented with critical behavioral details: the private key is shown only once and never stored, and the tool is gated by an environment variable. This adds security context and return-behavior information that the annotation alone does not convey, especially since no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three sentences, each serving a clear purpose: stating the action, describing the return and security, and providing usage guidance. There is no fluff or redundant wording, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description covers all essential aspects: what the tool does, what it returns, security/privacy traits, and an alternative command. This is sufficient for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters in the schema, so the description doesn't need to explain parameter usage. Per the rubric, the baseline for no parameters is 4, and the description adds no parameter-specific information because none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action and resource: 'Generate a new random Ethereum wallet.' It explicitly mentions the return of address and private key, distinguishing it from siblings like wallet_generate_mnemonic. The purpose is immediately understood and not conflated with other wallet operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Prefer local CLI: npx web3agent wallet generate,' providing a clear alternative and indicating when to avoid the tool. The gating requirement (WEB3AGENT_ALLOW_AGENT_VISIBLE_SECRETS=1) informs the agent of the environment variable needed, giving concrete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![web3agent MCP server](https://glama.ai/mcp/servers/Apegurus/web3agent/badges/card.svg)](https://glama.ai/mcp/servers/Apegurus/web3agent)

Score Badge

Copy to your README.md:

[![web3agent MCP server](https://glama.ai/mcp/servers/Apegurus/web3agent/badges/score.svg)](https://glama.ai/mcp/servers/Apegurus/web3agent)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Apegurus/web3agent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server