mcp-server

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

The description adds substantial behavioral context beyond the annotations: it requires reading skill files as a prerequisite, explains pagination mechanics via the 'pagination' field and next_call (GET only), supports POST for JSON RPC, and warns that endpoint paths/parameters vary per chain. This is rich, non-obvious behavior that helps correct invocation and expectations.

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

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

The description is moderately long (4 sentences plus a pagination note) but every sentence carries necessary information: purpose, prerequisite reads, POST support, and pagination. It is front-loaded with the purpose and structurally clear, though slightly dense. A tight, perfectly minimal version might be a 5, but this is appropriately sized for the tool's complexity.

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

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

Given the tool's complexity (7 params, generic raw access, many siblings) and the presence of an output schema, the description covers all critical aspects: purpose, prerequisites, method flexibility, pagination, and cross-version variability. It leaves no major gap for the agent to safely use the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself does not add new parameter semantics beyond what the schema already provides (e.g., endpoint_path's no-query-string rule, cursor pagination, POST with json_body are all in the schema descriptions). It neither compensates nor undercuts.

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

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

The description opens with 'Call a raw Blockscout API endpoint for advanced or chain-specific data'—a specific verb and resource. The word 'raw' clearly distinguishes this generic tool from the specialized sibling tools, and 'advanced or chain-specific data' signals that it covers cases beyond the specialized tools.

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

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

The description gives clear context: 'for advanced or chain-specific data' implies use when specialized tools are insufficient. It also mandates reading skill files before first use, which is a strong usage guideline. However, it does not explicitly name alternatives or state 'use this instead of X', so it gets a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds that it 'convert's an ENS name, but does not disclose additional behavioral details such as error handling for invalid names or reliance on external data. Given the annotation coverage, 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.

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

The description is a single, focused sentence that immediately conveys the tool's purpose with no extraneous content. It is front-loaded and well-structured.

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

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

For a simple lookup tool with full schema coverage, clear annotations, and an output schema, the description is complete. It does not need to explain return values because the output schema exists, and the one-sentence description adequately covers the tool's function.

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

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

The schema already describes both parameters with 100% coverage, so the baseline is 3. The description provides a concrete example 'blockscout.eth' which clarifies the expected format of the 'name' parameter, adding value beyond the schema. No additional information is given for session_id, but it is a generic opaque identifier.

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

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

The description clearly states the tool converts an ENS domain name to its corresponding Ethereum address, using a specific verb and resource. The example 'blockscout.eth' adds concrete context, and it is distinct from sibling tools which focus on blocks, transactions, or tokens.

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

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

The description says 'Useful for when you need to convert an ENS domain name' which clearly indicates the appropriate context. It does not explicitly mention alternatives or exclusions, but no other sibling tool serves this purpose, so the guidance is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context beyond those annotations: it states ETH balance is 'provided as is, without adjusting by decimals,' explains that first transaction details are used for age calculation, and details how proxy contract detection works. This gives the agent insight into the tool's behavior and output semantics beyond the 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.

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

The description is well-structured with a clear opening line followed by bullet points, making it easy to scan. Each bullet adds a specific capability detail. The final sentence about use cases is slightly promotional but still provides useful context. It is appropriately sized for a tool with this many features, though it could be trimmed without losing value.

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

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

Given the tool's complexity and the presence of an output schema, the description covers all major facets of the tool: existence, balances, transactions, ENS, contract/proxy status, and token details. It doesn't explain error handling or edge cases, but the output schema and annotations (openWorldHint) fill some gaps. The description is sufficiently complete for an agent to understand the tool's scope.

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

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

Schema description coverage is 100% — all three parameters (address, chain_id, session_id) have descriptions in the schema. The description does not add additional parameter-level meaning beyond what the schema provides (e.g., no format examples, no explanation of chain_id values). Per the rubric, baseline 3 is appropriate when schema covers parameters fully.

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

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

The description clearly states the tool's purpose with a specific verb ('Get comprehensive information about an address') and enumerates the exact data points returned (existence, ETH balance, first transaction, ENS, contract status, proxy info, token details). This distinguishes it from sibling tools like get_address_by_ens_name (which resolves ENS to address) and get_tokens_by_address (which lists tokens held by an address).

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

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

The description provides clear context for when to use the tool: 'Essential for address analysis, contract investigation, token research, and DeFi protocol analysis.' While it doesn't explicitly name alternatives or exclusions, the use cases imply when this comprehensive tool is appropriate vs. more specialized sibling tools. No misleading guidance.

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

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

Annotations already declare readOnlyHint and destructiveHint, so safety is covered. The description adds value by disclosing that transaction hashes are omitted by default and warning about the potential context impact on high-traffic chains, which are behavioral details not present in annotations.

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

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

The description is two sentences, front-loaded with the primary purpose, and includes the critical caution about transaction hashes. Every sentence earns its place with no wasted words.

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

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

Given the presence of an output schema and strong annotations, the description covers the core functionality, lists representative return fields, and highlights the one notable behavioral caveat. No important aspect is left unexplained.

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

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

The schema already describes all parameters fully, so the baseline is 3. The description adds meaningful context for include_transactions, explaining the cost/benefit beyond the schema's simple boolean description, which improves the semantic understanding.

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

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

The description clearly states the tool retrieves block information and lists specific data fields (timestamp, gas used, burnt fees, transaction count). This distinguishes it from siblings like get_block_number, which targets a single piece of data.

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

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

It gives explicit guidance on when to set include_transactions to true, noting the default is omitted and advising to request only when truly needed to avoid context exhaustion. It does not mention alternative tools, but the guidance is clear and actionable.

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

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

The description adds behavioral nuance beyond the read-only annotation, such as 'finds the block immediately preceding that time' and 'returns the latest indexed block,' implying possible indexing delay. It clarifies the return includes timestamp as well as number. 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.

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

The description is three sentences with no filler. It front-loads the purpose, then usage, then conditional behavior, each sentence adding value. It is appropriately sized for a simple tool.

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

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

For a tool with an output schema, the description covers the essential aspects: purpose, usage, and datetime behavior. It clarifies the 'latest' case as 'latest indexed block,' which is important context. With all parameters documented in the schema, the description is complete for this simple tool.

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

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

The schema already describes all three parameters, providing a baseline of 3. The description enriches the datetime parameter by specifying it finds the block immediately preceding the given time and that omitting it returns the latest indexed block. This adds semantic value beyond the schema's 'to find the block for.'

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

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

The description clearly states the tool retrieves block number and timestamp either for a given datetime or the latest block. It uses specific verb 'Retrieves' and resource 'block number and timestamp,' distinguishing it from sibling get_block_info which likely returns block details. The tool's 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.

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

The description explicitly states when to use the tool: when needing a block height for a specific point in time or the current chain tip. It doesn't explicitly name alternatives or when-not-to-use, but the use case is clearly defined. The distinction between providing or omitting datetime is explained.

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

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

Beyond the annotations (readOnly, openWorld, non-destructive), the description discloses important behavior: substring-based matching and the possibility of returning many chains for partial numeric IDs. This helps the agent anticipate results and adjust query strategy, adding value 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.

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

The description is concise, with four sentences, and front-loads the purpose. Every sentence contributes useful information: purpose, context, usage hints, and a specific warning. No wasted words.

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

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

The tool is simple with two optional parameters, an output schema exists, and annotations are rich. The description covers the core purpose, usage timing, and key behavioral caveat (substring matching). There is no significant missing context that the agent needs for correct invocation.

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

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

The schema already covers both parameters with detailed descriptions (e.g., query is case-insensitive substring across fields, session_id is opaque). The description reinforces but does not add significant new semantics beyond the schema. 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.

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

The description clearly states the tool 'Get supported blockchain chains with their chain IDs' with a specific verb and resource. It also distinguishes its purpose by noting that Ethereum Mainnet is chain_id 1 and that this tool resolves other chains, setting it apart from sibling tools.

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

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

The description explicitly says when to use this tool: when another tool needs a supported chain_id and only the chain name, ecosystem, or native currency is known. It also provides guidance to prefer a narrow query and warns against partial numeric chain ID queries due to substring matching, which is actionable and prevents misuse.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. However, the description does not disclose additional behavioral traits such as availability for unverified contracts or potential errors, so it adds limited 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.

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

The description is two concise sentences. The first states the action, and the second explains the concept of an ABI and its purpose. Every sentence earns its place with no redundancy.

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

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

For a simple read-only getter with a complete schema, annotations, and an output schema, the description adequately covers the tool's purpose and context. It explains what an ABI is and why it's needed, making it complete for agent orientation.

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

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

The input schema covers 100% of parameters with descriptions (address, chain_id, session_id), so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already provides.

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

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

The description clearly states the tool retrieves a smart contract ABI and explains what an ABI defines, giving a specific verb and resource. It does not explicitly distinguish from sibling tools like inspect_contract_code or read_contract, 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.

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

The description indicates the ABI is required to format function calls or interpret contract data, implying when the tool is needed. It does not mention alternatives or exclusions, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing that the balance is returned without decimal adjustment and that pagination requires using the next_call in the response. These are specific behavioral traits beyond the annotations, aiding the agent in handling responses correctly.

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

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

The description is concise at four sentences, front-loads the primary purpose, then details return contents, use cases, and pagination. Each sentence adds distinct value with no redundancy or verbose language, making it efficient for an agent to parse.

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

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

Given the presence of an output schema and rich annotations, the description covers essential behavioral context: it notes the raw balance, pagination handling, and typical use cases. While session_id is not mentioned in the description, the schema fully documents it, so no critical gaps exist. The description is adequate for safe and effective tool invocation.

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

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

All four parameters are fully described in the input schema, including cursor, address, chain_id, and session_id. The description reiterates address usage and pagination but introduces no new parameter semantics beyond the schema. Per guidelines, high schema coverage (100%) sets a baseline of 3, and the description does not elevate it.

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

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

The description clearly states the tool retrieves ERC20 token holdings for a specific address, with enriched metadata and market data. It distinguishes itself from sibling tools like get_token_transfers_by_address (transfers) and nft_tokens_by_address (NFTs) by focusing on current holdings and holdings details. The action verb 'Get' and specific resource 'ERC20 token holdings' make the purpose unambiguous.

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

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

The description explicitly identifies primary use cases: portfolio analysis, wallet auditing, and DeFi position tracking. However, it does not mention alternatives or when not to use this tool. The context is clear but lacks explicit exclusions, fitting the 'clear context, no exclusions' tier.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable context about pagination behavior (using next_call when the 'pagination' field appears) and the time-range constraint, going 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.

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

The description is two concise sentences with the critical pagination instruction prominently bolded. It is well-structured and contains no redundant information.

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

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

With 7 parameters and an output schema, the description covers the core purpose and pagination behavior, while annotations handle safety. The main gap is lack of usage guidance relative to sibling tools, but overall the description is sufficiently complete for a read-only list tool.

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

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

Schema description coverage is 100%, so the schema already documents all parameters clearly. The description adds a small note about pagination linking to the cursor parameter, but otherwise does not deepen understanding beyond the schema.

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

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

The description clearly states it retrieves ERC-20 token transfers for an address within a specified time range, using a specific verb and resource. It is implicitly distinct from siblings like get_transactions_by_address and get_tokens_by_address, but does not explicitly call out those alternatives.

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

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

No guidance is provided on when to use this tool versus similar alternatives (e.g., get_transactions_by_address, get_tokens_by_address). It does not mention exclusions, prerequisites, or typical use cases.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: raw input is omitted by default to save context, and include_raw_input=True is needed to retrieve it. This goes beyond the annotations and helps the agent understand the tool's default behavior and trade-offs.

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

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

The description is four sentences, front-loaded with the core purpose, and every sentence provides distinct value: what it does, how it differs, default behavior, and use cases. No fluff or repetition.

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

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

The tool has an output schema, so return values need not be explained. The description covers purpose, comparison to alternatives, default behavior, and appropriate use cases. Given the annotations and schema, the description is complete and leaves no critical gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the rationale behind include_raw_input (saving context) and advising when to use it ('only when you truly need the raw hex data'). This context is not present in the schema and helps the agent decide on parameter values.

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

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

The description clearly states the tool 'Get comprehensive transaction information' and immediately specifies what that means: enriched data including decoded input, token transfers, fee breakdowns, and categorized types. It differentiates the tool from the standard eth_getTransactionByHash and, by focusing on a single transaction, implies distinction from list-oriented siblings like get_transactions_by_address.

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

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

The description provides explicit use cases: 'Essential for transaction analysis, debugging smart contract interactions, tracking DeFi operations.' It does not explicitly name sibling alternatives or say when not to use, but the context and comparison to eth_getTransactionByHash give clear guidance. The absence of explicit exclusions keeps it from a 5.

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

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

Beyond the readOnlyHint/openWorldHint/destructiveHint annotations, the description adds critical behavioral details: token transfers are filtered out, a single transaction can produce multiple records due to internal calls, the age_from requirement for performance, and pagination behavior. This goes beyond the structured annotations and provides valuable context without contradiction.

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

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

The description is compact yet highly informative, using bold header-like cues for key exclusions and pagination. Every sentence serves a purpose: scope, exclusions, multi-record caveat, required input, and pagination. No filler or redundancy.

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

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

Given the tool's complexity (7 parameters, output schema present) and the rich annotations, the description covers all essential behaviors: what is retrieved, what is excluded, multi-record behavior, required field, and pagination instructions. It is fully adequate 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.

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

Schema description coverage is 100%, so the schema already documents all parameters with detailed descriptions. The tool description adds minimal extra value for parameter understanding, only reinforcing the age_from requirement and pagination via cursor/next_call. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool retrieves native currency transfers and smart contract interactions for an address, with an explicit exclusion of token transfers. It distinguishes itself from the sibling tool get_token_transfers_by_address by naming that alternative for token history, so the purpose is specific and well-scoped.

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

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

The description gives explicit when-to-use guidance: for token history, use get_token_transfers_by_address instead, and requires an age_from date to scope results. It also explains pagination usage with the 'pagination' field and next_call, providing clear context for when and how to use the tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds a 'verified' constraint, implying the contract must be verified to succeed. It does not mention behavior for unverified contracts or error cases, but this is acceptable given annotation coverage.

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

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

A single, front-loaded sentence containing all essential information with no redundant words. Perfectly concise.

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

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

With full schema coverage, output schema, and safety annotations, the description sufficiently covers the tool's purpose. It could have benefited from a brief note about when to use this vs. get_contract_abi, but the core context is present.

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

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

Schema description coverage is 100%, so the description need not elaborate parameters. The phrase 'or metadata' hints at the file_name optionality, but no additional semantic value is added beyond schema.

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

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

The description states a specific verb ('Inspects') and resource ('verified contract's source code or metadata'), clearly distinguishing it from siblings like get_contract_abi (which fetches ABI) and read_contract (which executes calls). The mention of 'verified' adds a key qualifier.

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

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

Usage is implied: use when needing source code or metadata of a verified contract. However, it does not explicitly contrast with sibling tools like get_contract_abi or read_contract, nor does it provide 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.

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

Beyond the annotations (readOnlyHint true, destructiveHint false), the description adds important behavioral details: matches are based on symbol/name similarity, multiple potential matches may be returned, and only the first 7 from the Blockscout API are included. This provides useful context about the fuzzy matching and result truncation behavior.

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

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

The description is three concise sentences, each serving a purpose: what it does, the nature of results, and the limit. It is front-loaded with the action and contains no filler or repetition.

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

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

Given the output schema and annotations, the description covers key contextual gaps: the fuzzy matching behavior and the 7-match limit. It does not explicitly state behavior for no matches, but that is likely covered by the output schema. Overall, it is sufficiently complete for a search tool with a structured response.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds semantic value by explaining that the search uses 'symbol or token name similarity' and returns 'potential matches', indicating fuzzy matching rather than exact lookup. This goes beyond the schema's simple 'Token symbol or name to search for'.

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

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

The description states 'Search for token addresses by symbol or name' with a specific verb and resource, and clarifies it returns multiple potential matches. It is clearly distinguished from siblings like get_tokens_by_address by focusing on symbol/name lookup rather than address-based queries.

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

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

The description clearly implies when to use this tool: when you need to find token addresses from a symbol or name. It notes that results are based on similarity and only the first 7 matches are returned, helping set expectations. However, it does not explicitly name alternatives or exclusions, though the purpose makes the use case obvious.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: grouping by collection, providing collection details and token instance data, and explicit pagination instructions ('If response includes 'pagination' field, use the provided next_call'). This goes beyond annotations without contradicting them.

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

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

Four sentences, front-loaded with the core action, then details and pagination note. Every sentence contributes value; no fluff or repetition. The structure is scannable and efficient.

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

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

Given the output schema exists, the description needn't restate return values. It explains the collection grouping, included fields (type, address, name, symbol, total supply, holder count, token instance data), and pagination behavior. Complete for a read-only NFT query tool.

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

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

Schema coverage is 100%, with each parameter already described (e.g., cursor is 'pagination cursor from previous response'). The description reinforces the cursor usage but doesn't add new meaning beyond the schema. Baseline of 3 is appropriate because the schema carries the semantic load.

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

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

The description clearly states the tool retrieves NFT tokens (ERC-721, ERC-404, ERC-1155) owned by an address, grouped by collection. The verb 'Retrieve' and specific resource distinguish it from sibling tools like get_tokens_by_address (which likely handles fungible tokens) and get_token_transfers_by_address.

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

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

The description says it's 'Essential for a detailed overview of an address's digital collectibles and their associated collection data,' implying use for NFT-focused queries. It does not explicitly mention alternatives or exclusions, but the standard list and context differentiate it from siblings. Clear context but no explicit when-not-to-use.

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

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

Annotations already mark this as read-only and non-destructive. The description adds that non-view/pure functions are simulated via eth_call, making it clear there is no state change. It also notes the result is decoded, which is useful behavioral information.

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

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

The core description is two sentences, though the second is somewhat redundant with the first. The included example is large but provides valuable, concrete parameter formatting guidance, justifying its inclusion.

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

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

Given the complexity of seven parameters and the presence of an output schema, the description covers the essential behavior and a full example. It does not explain every parameter, but the schema handles that, and the example fills in practical usage gaps.

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

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

The schema covers all parameters with descriptions, and the example demonstrates how to format args, ABI, and addresses. It clarifies JSON string formatting for args and address conventions, exceeding basic schema descriptions.

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

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

The description clearly states it calls a smart contract function (view/pure, or non-view/pure simulated via eth_call) and returns the decoded result. This specifies the exact action and resource, distinguishing it from generic API calls or ABI inspection tools. The example reinforces the use case of querying token balances.

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

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

The description identifies this as 'a direct way to query the state of a smart contract,' giving clear context for when to use it. It does not explicitly name alternatives or exclusions, but the context and sibling set make the appropriate use case evident. The example provides a concrete scenario.

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

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

No contradiction with annotations; readOnlyHint and openWorldHint align with a non-destructive initialization. The description adds important behavioral context: the one-time per-session nature and the need to reuse the returned payload, which is not conveyed by annotations alone.

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

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

The description is concise, front-loaded with the action and return value, and contains only essential usage guidance. Every sentence 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.

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

Given that an output schema exists, the description need not detail return structure. It fully covers the tool's role, the required call order, and the reuse rule, making it complete for an initialization tool in a broader toolset.

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

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

The tool has zero parameters, so the input schema fully covers parameter semantics. The description appropriately focuses on session initialization rather than parameter details, and the baseline for zero-parameter tools is 4.

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

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

The description clearly states the tool's purpose: 'Initializes a Blockscout MCP session' and enumerates exactly what it returns. It is distinct from all sibling tools, which perform direct data lookups, making this a unique session bootstrap tool.

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

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

Provides explicit usage instructions: 'Call this tool exactly once per session, before any other tool', and 'do not call it again.' This leaves no ambiguity about when to use the tool and when to avoid repeated calls.

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