Server Quality Checklist

Tool Scores

• inspect_contract_codeB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds that it inspects 'verified contract's source code or metadata', which implies a read operation consistent with annotations, but doesn't provide additional behavioral context like rate limits, authentication needs, or what 'verified' entails.

  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 that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.

  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 3 parameters with full schema coverage and annotations covering safety, the description is adequate but lacks output details (no output schema) and doesn't fully address sibling tool differentiation or usage context, leaving some gaps for an AI agent.

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

  Parameters3/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 in the schema. The description mentions 'source code or metadata' and implies conditional behavior with 'file_name', adding some context, but doesn't provide extra semantic details beyond what the schema already covers.

  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 ('inspects') and resource ('verified contract's source code or metadata'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_contract_abi' or 'read_contract', which might have overlapping functionality with smart contracts.

  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 'get_contract_abi' or 'read_contract'. It mentions the conditional behavior with 'file_name' but doesn't explain broader context or prerequisites for inspecting verified contracts.

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

• lookup_token_by_symbolA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context beyond annotations: it specifies that results are based on 'similarity' (not exact matches), returns 'multiple potential matches', and is limited by 'TOKEN_RESULTS_LIMIT' from the Blockscout API. This enhances transparency about output behavior and constraints, though it doesn't cover rate limits or error handling.

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

  Conciseness5/5

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

  The description is highly concise and well-structured in three sentences: it states the purpose, clarifies the return behavior (multiple matches based on similarity), and specifies the limitation (TOKEN_RESULTS_LIMIT from Blockscout API). Every sentence adds essential information without redundancy, making it efficient and front-loaded 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 the tool's moderate complexity (search with similarity matching), lack of output schema, and rich annotations (readOnlyHint, openWorldHint), the description is mostly complete. It covers key behavioral aspects like similarity-based matching and result limits, but doesn't explain the return format (e.g., what data fields are included) or potential errors, leaving some gaps in full contextual understanding.

  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 clear descriptions for both parameters ('chain_id' as blockchain ID and 'symbol' as token symbol or name). The description adds minimal semantic value beyond the schema, only implying that 'symbol' is used for similarity-based searching. Since the schema already documents parameters well, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter 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 tool's purpose: searching for token addresses by symbol or name and returning multiple potential matches. It specifies the verb ('Search for'), resource ('token addresses'), and scope ('by symbol or name'). However, it doesn't explicitly differentiate from sibling tools like 'get_tokens_by_address' or 'nft_tokens_by_address', which prevents a perfect score.

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

  Usage Guidelines3/5

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

  The description implies usage context by mentioning it returns matches based on 'symbol or token name similarity' and is limited to 'TOKEN_RESULTS_LIMIT' from the Blockscout API. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_tokens_by_address' or 'direct_api_call', and doesn't specify prerequisites or exclusions, leaving usage somewhat ambiguous.

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

• get_address_by_ens_nameA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds useful context about the conversion process but does not disclose behavioral traits like rate limits, error handling, or what happens with invalid ENS names.

  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 that is front-loaded with the tool's purpose. There is no wasted text, and it directly addresses the core functionality 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?

  Given the simple single-parameter input, high schema coverage, and annotations covering safety, the description is adequate. However, without an output schema, it does not explain return values (e.g., address format, null for unresolved names), leaving some gaps in 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 the parameter 'name' well-documented in the schema. The description adds minimal value by reinforcing that it's an 'ENS domain name' but does not provide additional semantics 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 clearly states the tool's purpose with a specific verb ('convert') and resource ('ENS domain name to Ethereum address'), and distinguishes it from siblings by focusing on ENS resolution rather than general address info or blockchain data 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?

  The description provides clear context for when to use this tool ('when you need to convert an ENS domain name'), but does not explicitly mention when not to use it or name alternatives like 'get_address_info' which might handle non-ENS addresses.

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

• get_contract_abiA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context by explaining what an ABI is and its purpose (formatting function calls, interpreting data), which helps the agent understand the tool's role beyond just being a read operation. It doesn't mention rate limits or authentication needs, but with annotations covering safety, 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 front-loaded with the core purpose in the first sentence, followed by explanatory context that earns its place by clarifying the ABI's role. It uses three concise sentences with no redundant information, making it 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?

  Given the tool's moderate complexity (2 parameters, read-only operation) and rich annotations (readOnlyHint, openWorldHint), the description is mostly complete. It explains the tool's purpose and the ABI's utility, though it doesn't detail output format or error cases, which is a minor gap since there's no output 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?

  Schema description coverage is 100%, with clear descriptions for both parameters ('chain_id' as blockchain ID, 'address' as smart contract address). The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 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 specific action ('Get smart contract ABI') and resource ('Application Binary Interface'), with additional explanation of what an ABI defines. It distinguishes this tool from siblings like 'inspect_contract_code' (which likely retrieves bytecode) and 'read_contract' (which likely executes contract functions).

  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 explaining that 'The ABI is required to format function calls or interpret contract data,' suggesting this tool is needed before using contract interaction tools. However, it doesn't explicitly state when to use this tool versus alternatives like 'inspect_contract_code' or provide clear exclusions.

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

• get_address_infoA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable behavioral context beyond annotations by specifying what information is returned (e.g., 'Native token balance provided as is, without adjusting by decimals'), which helps the agent understand output format nuances that annotations don't capture.

  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 appropriately sized and front-loaded with the core purpose, followed by a bulleted list of specific information returned, and ending with usage context. While efficient, the bulleted list format slightly reduces structural elegance compared to a purely prose approach.

  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 (comprehensive address analysis) and lack of output schema, the description does a good job explaining what information is returned through the detailed bullet points. However, it doesn't specify response format structure or potential limitations (e.g., rate limits, data freshness), leaving some 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?

  Schema description coverage is 100%, with both parameters (chain_id, address) well-documented in the schema. The description doesn't add any parameter-specific semantics beyond what the schema already provides, maintaining the baseline score of 3 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 tool's purpose with specific verbs ('Get comprehensive information about an address') and lists detailed resource types (address existence, token balance, ENS name, contract status, proxy info, token details). It distinguishes from siblings by focusing on comprehensive address analysis rather than specific operations like get_transactions_by_address or get_contract_abi.

  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 this tool ('Essential for address analysis, contract investigation, token research, and DeFi protocol analysis'), giving concrete use cases. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for more targeted operations.

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

• read_contractA
  4.1/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true and destructiveHint=false, which the description reinforces by emphasizing 'query' and 'read' operations. The description adds valuable context beyond annotations: it explains that both view/pure functions AND non-view/pure functions (via eth_call simulation) can be called, and mentions the tool returns 'decoded result' (helpful since there's no output schema). No contradiction with annotations.

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

  Conciseness4/5

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

  The description is well-structured with a clear purpose statement, usage context, and detailed example. The example is lengthy but necessary to demonstrate complex parameter interactions. Some sentences could be more concise, but overall it's efficiently organized with front-loaded key 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 complex tool with 6 parameters, 100% schema coverage, and no output schema, the description provides good context. It explains the tool's behavior, includes a comprehensive example showing parameter usage, and clarifies the return type ('decoded result'). It could mention error cases or limitations, but covers the essential functionality well.

  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 documents all 6 parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema descriptions, though the example illustrates how parameters work together. Baseline 3 is appropriate when schema does the heavy lifting.

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

  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: 'Calls a smart contract function (view/pure, or non-view/pure simulated via eth_call) and returns the decoded result.' It specifies the verb ('calls'), resource ('smart contract function'), and scope ('view/pure' functions or simulated calls). It distinguishes from siblings by focusing on contract state queries rather than transactions, blocks, or token lookups.

  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: 'This tool provides a direct way to query the state of a smart contract.' It implies usage for read-only contract interactions, but doesn't explicitly state when NOT to use it or name specific alternatives. The example shows a balance check, which helps illustrate appropriate use cases.

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

• get_tokens_by_addressA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context: it discloses pagination support with instructions on using the 'next_call', specifies that balance is provided 'as is, without adjusting by decimals', and mentions enriched metadata and market data. This goes beyond annotations without contradiction.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds value: details on return data, use cases, and pagination instructions. There is no wasted text, and it efficiently conveys necessary information in four concise sentences.

  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 compensates by detailing return values: 'contract details (name, symbol, decimals), market metrics (exchange rate, market cap, volume), holders count, and actual balance'. It also covers pagination behavior. However, it lacks error handling or rate limit information, which could be useful given the openWorldHint annotation.

  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 parameters (chain_id, address, cursor). The description adds no specific parameter semantics beyond what the schema provides, such as format examples or constraints for 'address' or 'chain_id'. Baseline 3 is appropriate when schema handles parameter documentation.

  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 resource 'ERC20 token holdings for an address' with specific scope 'comprehensive...with enriched metadata and market data'. It distinguishes from siblings like 'nft_tokens_by_address' (NFTs vs ERC20) and 'get_token_transfers_by_address' (transfers vs holdings).

  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 states use cases: 'portfolio analysis, wallet auditing, and DeFi position tracking', providing clear context for when to use this tool. However, it does not mention when not to use it or name specific alternatives among siblings, such as 'nft_tokens_by_address' for NFTs instead of ERC20 tokens.

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

• nft_tokens_by_addressA
  4.2/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond what annotations provide. While annotations declare readOnlyHint=true and destructiveHint=false, the description specifies that results are 'grouped by collection' and provides details about the response structure (collection details and individual token instance data). Most importantly, it explicitly documents pagination behavior with specific instructions about the 'pagination' field and 'next_call', which is critical operational knowledge not captured in annotations.

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

  Conciseness5/5

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

  The description is efficiently structured with three focused sentences and a bold pagination note. The first sentence states the core functionality, the second details the response structure, the third provides usage context, and the pagination note delivers critical operational guidance. Every sentence earns its place with no 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 but no output schema, the description provides excellent context about what the tool returns (collection details and token instance data) and critical pagination behavior. It could potentially benefit from mentioning response format specifics or error conditions, but given the annotations cover safety aspects and the description explains the response structure well, it's quite complete for agent 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?

  With 100% schema description coverage, the input schema already fully documents all three parameters (chain_id, address, cursor). The description doesn't add any parameter-specific information beyond what's in the schema, but the baseline of 3 is appropriate when the schema provides complete parameter documentation.

  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 specific verbs ('retrieve NFT tokens owned by an address') and resources (ERC-721, ERC-404, ERC-1155 tokens). It distinguishes from sibling tools like 'get_tokens_by_address' by specifying NFT tokens grouped by collection rather than general tokens, and from 'get_address_info' by focusing on NFT holdings specifically.

  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 this tool: for getting a detailed overview of an address's digital collectibles with collection data. It doesn't explicitly state when NOT to use it or name specific alternatives, but the context is sufficiently clear for an agent to understand this is for NFT holdings analysis rather than general token balances or address metadata.

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

• transaction_summaryA
  4.2/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, read-only operation with potential for unknown data. The description adds valuable behavioral context beyond this: it discloses that 'Not all transactions can be summarized and accuracy is not guaranteed for complex patterns,' which is crucial for understanding limitations. However, it doesn't mention rate limits, authentication needs, or response format 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 efficiently structured with four sentences that each serve a distinct purpose: stating the core function, detailing classification capabilities, specifying use cases, and disclosing limitations. There's no wasted text, and key information is front-loaded, making it easy for an agent to quickly understand the tool's 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 moderate complexity (2 required parameters), rich annotations (readOnlyHint, openWorldHint), and lack of output schema, the description is mostly complete. It covers purpose, usage, and limitations well. However, it doesn't describe the output format (e.g., what the summary looks like), which would be helpful since there's no output schema. The annotations help compensate, but some gaps remain.

  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 (chain_id and transaction_hash) well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. It doesn't compensate for gaps because there are none, but also doesn't provide extra semantic context.

  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 human-readable transaction summaries from Blockscout Transaction Interpreter' with specific details about classification into natural language descriptions (transfers, swaps, NFT sales, DeFi operations). It distinguishes itself from sibling tools like 'get_transaction_info' by focusing on summarized, human-readable interpretations rather than raw transaction 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 for when to use this tool: 'Essential for rapid transaction comprehension, dashboard displays, and initial analysis.' It doesn't explicitly mention when NOT to use it or name specific alternatives, but the context strongly implies it's for summary purposes rather than detailed analysis, which differentiates it from siblings like 'get_transaction_info'.

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

• direct_api_callA
  4.3/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, read-only operation with flexible endpoints. The description adds valuable context beyond this: it explains pagination support ('If response includes 'pagination' field, use the provided next_call'), clarifies return type handling ('Must return ToolResponse[Any]'), and warns about query parameter encoding. This enhances behavioral understanding 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.

  Conciseness4/5

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

  The description is well-structured and front-loaded with the core purpose, followed by specific instructions and return details. It uses bold for key points like 'SUPPORTS PAGINATION' and code formatting for parameters. While slightly verbose in the return type explanation, most sentences earn their place by providing critical 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 tool's complexity (open-world API calls) and lack of output schema, the description is reasonably complete: it covers purpose, usage rules, pagination, and return type nuances. However, it could benefit from more examples or error-handling context. Annotations provide safety cues, but the description adequately supplements them for agent 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 the schema fully documents all four parameters. The description adds minimal param-specific semantics: it reiterates not to include query strings in 'endpoint_path' and mentions pagination via 'cursor', but these are largely covered in schema descriptions. This meets the baseline of 3 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 tool's purpose: 'Call a raw Blockscout API endpoint for advanced or chain-specific data.' It specifies the verb ('Call'), resource ('Blockscout API endpoint'), and scope ('advanced or chain-specific data'), distinguishing it from sibling tools that perform specific, predefined queries like 'get_address_info' or 'get_transaction_info'.

  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: it instructs to use this tool for 'advanced or chain-specific data' (implying when sibling tools are insufficient), warns against including query strings in 'endpoint_path', and details pagination handling. This clearly defines when and how to use it versus the more specialized sibling tools.

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

• get_transaction_logsA
  4.3/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable behavioral context: it explains the enriched nature of the logs (decoded event parameters with types/values), mentions pagination support with specific implementation details, and clarifies the focus on event analysis rather than raw data. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is well-structured and appropriately sized. It starts with the core purpose, differentiates from alternatives, lists use cases, and ends with pagination details. Every sentence adds value, though the use case list could be slightly more concise. Good front-loading of essential 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?

  Given the tool's complexity (transaction log analysis with decoding), the description provides good context about what makes this tool special (enriched logs, decoded parameters). With annotations covering safety/scope and 100% schema coverage, the main gap is no output schema, but the description gives some indication of return format (pagination field, next_call). Could benefit from more detail about response structure.

  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 fully documents all three parameters (chain_id, transaction_hash, cursor). The description doesn't add any parameter-specific semantics beyond what's in the schema, but it does mention pagination context which relates to the cursor parameter. Baseline 3 is appropriate when schema coverage is complete.

  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 comprehensive transaction logs' with specific differentiation from 'standard eth_getLogs' by emphasizing enriched logs with decoded event parameters. It distinguishes from sibling tools like get_transaction_info by focusing on logs/events rather than general transaction data.

  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: 'Essential for analyzing smart contract events, tracking token transfers, monitoring DeFi protocol interactions, debugging event emissions, and understanding complex multi-contract transaction flows.' This gives clear context for when to use this tool versus alternatives like get_transaction_info or get_transactions_by_address.

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

• get_transactions_by_addressA
  4.3/5.0
  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 agent knows this is a safe read operation. The description adds valuable behavioral context beyond annotations: it explains pagination behavior ('SUPPORTS PAGINATION'), clarifies that a single transaction can have multiple records from internal calls, and provides guidance on using 'internal_transaction_index' for execution order. This adds meaningful operational context.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, exclusions, internal transaction explanation, use cases, pagination). It's appropriately sized for the tool's complexity, though the use case examples could be slightly more concise. Most sentences earn their place by providing valuable 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?

  Given the tool's complexity (6 parameters, no output schema), the description provides good contextual completeness. It explains what the tool returns (native transfers and smart contract interactions), what it excludes (token transfers), how to handle internal transactions, provides use case examples, and explains pagination. The main gap is lack of information about return format or structure, but this is mitigated by the comprehensive parameter guidance.

  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 documents all 6 parameters thoroughly. The description provides use case examples that illustrate how parameters work together (e.g., showing age_from alone vs with age_to and methods), but doesn't add significant semantic value beyond what's already in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.

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

  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 native currency transfers and smart contract interactions (calls, internal txs) for an address' and explicitly distinguishes it from sibling tools by stating 'EXCLUDES TOKEN TRANSFERS' and pointing to 'get_token_transfers_by_address' for token history. This provides specific verb+resource+scope with clear 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 Guidelines5/5

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

  The description provides explicit guidance on when to use this tool vs alternatives: 'For token history, use get_token_transfers_by_address'. It also includes specific use cases with parameter examples and explains what the tool excludes, giving clear context for when to use this tool and when not to.

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

• get_block_infoA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable behavioral context about the performance impact of including transactions ('may exhaust the context'), which goes beyond what annotations provide. 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 well-structured sentences: first states the core purpose with examples, second provides crucial usage guidance about the transactions parameter. Every word earns its place with no redundancy or fluff.

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

  Completeness4/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 full schema coverage, the description provides excellent context about the key performance consideration (transaction list exhausting context). The main gap is lack of output format details, but with no output schema, this would be helpful to include.

  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 documents all three parameters thoroughly. The description adds some context about the include_transactions parameter's default behavior and performance implications, but doesn't provide additional semantic meaning beyond what's in the 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 verb 'Get' and the resource 'block information', then provides specific examples of what information is retrieved (timestamp, gas used, burnt fees, transaction count). It distinguishes this tool from siblings like get_latest_block by focusing on specific block retrieval rather than latest block.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use the include_transactions parameter: 'request them only when you truly need them, because on high-traffic chains the list may exhaust the context.' This gives clear context about performance implications and when to avoid using this feature.

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

• get_latest_blockA
  4.4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable context beyond this: it clarifies that the data is 'indexed' (implying potential lag from real-time), specifies the return includes 'block number and timestamp,' and notes the limitation about transactions/token transfers. 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 core purpose, followed by usage context. Every sentence adds value: the first defines the tool, and the second explains its utility and limitations. 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?

  Given the tool's low complexity (one parameter, read-only, no output schema), the description is largely complete. It covers purpose, usage, and behavioral context. However, it could slightly improve by hinting at the return format (e.g., structured data with fields) since there's no output schema, but the annotations and clarity mitigate this 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%, with the parameter 'chain_id' fully documented in the schema as 'The ID of the blockchain.' The description does not add any additional meaning or clarification about this parameter beyond what the schema provides, so it meets the baseline for high 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 specific action ('Get the latest indexed block number and timestamp') and resource ('blockchain'), distinguishing it from siblings like get_block_info (which retrieves details for a specific block) or get_chains_list (which lists available chains). It precisely defines what the tool returns.

  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 states when to use this tool: 'useful as a reference timestamp for other API calls.' It also implies when not to use it by noting 'No transactions or token transfers can exist beyond this point,' suggesting alternatives like get_transactions_by_address for transaction data beyond this reference.

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

• get_token_transfers_by_addressA
  4.4/5.0
  Behavior4/5

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

  While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: it explicitly states support for pagination with specific instructions on how to handle it, warns about performance implications of omitting age_from, and clarifies that transfers include both to and from the address. This goes beyond what annotations provide.

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

  Conciseness5/5

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

  The description is efficiently structured with a clear purpose statement followed by specific use cases and important behavioral notes. Every sentence serves a distinct purpose: establishing the core function, demonstrating parameter usage, and providing critical implementation guidance about pagination. 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 read-only tool with comprehensive schema documentation but no output schema, the description provides excellent context: it explains what data is returned (ERC-20 token transfers), includes practical usage patterns, addresses performance considerations, and documents pagination behavior. The main gap is lack of information about return format/structure.

  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?

  With 100% schema description coverage, the input schema already thoroughly documents all 6 parameters. The description adds minimal parameter semantics beyond the schema, mainly through usage examples that show parameter combinations. It doesn't provide additional format details or constraints beyond what's in the 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 specific action ('Get ERC-20 token transfers') and resource ('for an address within a specific time range'), distinguishing it from sibling tools like get_transactions_by_address or get_tokens_by_address by focusing specifically on token transfers rather than general transactions or token holdings.

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

  Usage Guidelines5/5

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

  The description provides explicit usage examples with different parameter combinations, showing when to use specific parameter sets (e.g., with/without age_to, with/without token). It also includes guidance about pagination handling and strongly recommends providing age_from to avoid heavy queries, giving clear operational context.

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

• get_transaction_infoA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable behavioral context beyond annotations: it specifies that raw input is omitted by default to save context, explains the enriched data types returned (decoded parameters, token metadata, fee breakdown), and notes the tool's utility for specific use cases. No contradictions with annotations exist.

  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 well-structured and front-loaded, starting with the core purpose, followed by key differentiators, parameter guidance, and use cases. Each sentence adds distinct value without redundancy, and the length is appropriate for the tool's complexity. There is no wasted text.

  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 (enriched transaction data) and lack of an output schema, the description does a good job explaining what information is returned (decoded parameters, token transfers with metadata, fee breakdown, transaction types). However, it doesn't detail the exact structure or format of the enriched data, which could be helpful for an agent. Annotations cover safety aspects 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 description coverage is 100%, so the schema fully documents the three parameters (chain_id, transaction_hash, include_raw_input). The description adds minimal semantic value beyond the schema: it clarifies that include_raw_input=True is for 'raw hex data' and implies chain_id selects the blockchain, but doesn't provide additional details like format examples or constraints. 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 tool's purpose with specific verbs ('get comprehensive transaction information') and resources ('transaction'), distinguishing it from siblings like 'transaction_summary' by emphasizing enriched data including decoded parameters, token transfers, fee breakdown, and transaction types. It explicitly contrasts with standard eth_getTransactionByHash, establishing its unique value.

  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 guidance on when to use this tool ('essential for transaction analysis, debugging smart contract interactions, tracking DeFi operations') and when to use the include_raw_input parameter ('only when you truly need the raw hex data'). It implicitly contrasts with simpler alternatives like 'transaction_summary' by highlighting comprehensive data, though it doesn't name specific siblings as alternatives.

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

• get_chains_listA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, read-only operation with potentially dynamic data. The description adds value by specifying that it returns 'known blockchain chains with their IDs,' implying a static or reference list, which provides 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 that front-load the purpose and follow with usage guidance. Every sentence earns its place by providing essential information without waste, making it highly 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?

  Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is complete enough for an agent to understand and invoke it correctly. It explains the purpose, usage, and output context adequately, though it could briefly mention the format of the returned list (e.g., as key-value pairs) for slightly better 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?

  The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description does not need to add parameter information, and it appropriately focuses on the tool's purpose and usage without redundancy.

  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 resource ('list of known blockchain chains with their IDs'), making the purpose specific and unambiguous. It distinguishes this tool from siblings by focusing on chain metadata rather than addresses, transactions, contracts, or tokens.

  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 states when to use this tool: 'Useful for getting a chain ID when the chain name is known' and 'This information can be used in other tools that require a chain ID.' It provides clear context for usage without needing to specify exclusions, as the sibling tools are distinct in function.

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

• __unlock_blockchain_analysis__A
  4.6/5.0
  Behavior4/5

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

  The description adds significant behavioral context beyond annotations: it explains that all tools remain locked until this is called, that it returns essential rules for blockchain interactions, and that it provides a catalog of data sources. While annotations indicate read-only and non-destructive behavior, the description enriches understanding of the initialization mechanism and post-call requirements.

  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 well-structured with clear sections: purpose, mandatory nature, and data sources. Each sentence adds value, though it could be slightly more concise by combining some of the imperative warnings. The information is front-loaded with the core purpose in the first sentence.

  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 initialization tool with annotations covering safety (readOnlyHint, destructiveHint), the description is complete: it explains the prerequisite role, consequences of skipping it, what it returns (rules and data source catalog), and how it enables other tools. No output schema exists, but the description adequately covers expected outcomes.

  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 0 parameters and 100% schema coverage, the baseline would be 4. The description adds value by explaining why there are no parameters (it's a simple unlock/initialization function) and what happens when called, which goes beyond the empty 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 purpose as 'Unlocks access to other MCP tools' and explains it initializes the session to prevent 'Session Not Initialized' errors. It distinguishes itself from all sibling tools by being the mandatory initialization step rather than a data retrieval or analysis 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: 'MANDATORY FOR AI AGENTS' indicates this must be called first, 'Skipping this explicit initialization step will cause all subsequent tool calls to fail' explains the consequence of not using it, and it implicitly positions this as a prerequisite to all other blockchain tools in the sibling list.

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