Boar blockchain MCP (advanced)

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

Adds return format ('hex-encoded return data') beyond annotations and reinforces read-only nature without contradicting readOnlyHint/openWorldHint.

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?

Three sentences, front-loaded with action, each earning its place—no fluff 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?

Sufficient for standard Ethereum RPC; compensates for missing output schema by describing return format, though could note gas-free nature explicitly.

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 has 100% description coverage; description adds no parameter-specific semantics but baseline 3 is appropriate given comprehensive 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?

Specific verb ('Execute') + resource ('read-only smart contract call on Ethereum mainnet') clearly distinguishes from mezo_call siblings and decoding 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?

Explicitly states when to use ('read contract state without sending a transaction') but omits guidance on when to prefer eth_multicall for batch operations.

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?

Adds valuable behavioral context beyond annotations by stating 'Pure computation — no RPC call needed', clarifying it runs locally without blockchain interaction; no contradictions with readOnly/openWorld annotations.

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

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

Extremely concise two-sentence structure front-loaded with purpose; every clause delivers value (action, mechanism, input source, behavioral trait) with zero 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?

Adequately complete for a pure computation tool with simple inputs; mentions output format ('function name and typed arguments') compensating for missing output schema, though could explicitly confirm return structure.

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 has 100% description coverage with clear param definitions; description references 'provided ABI' and 'hex calldata' but adds no semantic information beyond what schema already provides, meeting baseline expectation.

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?

Specific action (decode into function name and typed arguments), clear resource (calldata using ABI on mainnet), and distinguishes from siblings via 'no RPC' vs eth_call and explicit 'calldata' focus vs decode_log/return/revert variants.

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 clear context on input sources ('from a transaction input or eth_call') and implies local usage via 'no RPC call needed', though lacks explicit 'when not to use' or alternative recommendations.

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?

Adds 'Pure computation — no RPC call needed' reinforcing readOnly annotation, and clarifies mainnet scope; no contradictions.

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

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

Three sentences, front-loaded with core action; each line adds distinct value (purpose, behavior, input source).

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?

Adequately covers input transformation and mentions 'named fields' for output; sufficient given rich input schema and absence of output schema.

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

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

Exceeds 100% schema coverage baseline by specifying topics/data originate from transaction receipts, adding provenance context.

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?

Specific verb (decode), resource (raw event log), and mechanism (ABI); explicitly scopes to 'Ethereum mainnet' distinguishing from mezo_decode_log sibling.

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?

Specifies input provenance ('from a transaction receipt log entry') and computational nature, though lacks explicit 'when not to use' vs calldata/return decoders.

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?

Adds valuable 'Pure computation — no RPC call needed' beyond readOnlyHint annotation, clarifying local execution nature.

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?

Two sentences, both high-value; front-loaded action statement with critical behavioral note; no fluff.

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?

Lacks output schema but describes return concept ('typed values'); sufficient for simple utility given complete input documentation.

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

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

Schema has 100% description coverage; description reinforces ABI/function_name usage but adds no new param constraints or semantics 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?

Specific verb (Decode) + resource (raw return data from eth_call) + network scope (Ethereum mainnet) clearly distinguishes from mezo_* siblings and other eth_decode_* variants.

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?

Implies workflow ('from an eth_call') and distinguishes network context, but lacks explicit when-not-to-use guidance or alternative mentions (e.g., mezo_decode_return).

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?

Adds valuable 'Pure computation — no RPC call needed' beyond readOnlyHint annotation, and explains behavior across different revert types (Error, Panic, silent).

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 tightly written sentences: purpose, capabilities, behavioral note, and usage instruction—no redundancy, perfectly front-loaded.

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?

Comprehensive given no output schema exists; describes decode targets (Error string, Panic code) implicitly covering return values, though explicit output format mention would strengthen it further.

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% but description reinforces ABI necessity for custom errors and clarifies revert_data source (hex from receipt/error response), adding practical context.

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?

Specific verb (Decode) + resource (EVM revert data), explicitly scopes to Ethereum mainnet distinguishing from mezo_decode_revert sibling, and clarifies handling of Error/Panic/custom/silent revert types.

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?

Clear context (failed transactions or eth_call), mentions ABI requirement for custom errors, and identifies data sources (transaction receipt/eth_call error), but lacks explicit contrast with non-revert decoding siblings.

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?

Adds critical context beyond annotations: clarifies 'no RPC call' distinction from readOnlyHint and warns about JS number precision loss for uint/int values.

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 tight sentences: purpose, input options with example, precision warning, and behavioral note—every sentence earns its place with no fluff.

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?

Well-covered given input schema richness; explains output type ('calldata hex') despite no output schema, though could explicitly state return format.

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

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

With 100% schema coverage (baseline 3), adds crucial semantic relationships: mutual exclusivity of signature vs abi+function_name and decimal string requirement for numeric args.

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?

States specific action ('Encode a function call into ABI-encoded calldata hex') and distinguishes from RPC-calling siblings via 'Pure computation — no RPC call needed'.

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?

Explains dual input modes (signature vs abi+function_name) and precision requirements, but lacks explicit 'when to use vs eth_call' guidance despite implying it.

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?

Adds crucial context beyond annotations: specific Multicall3 contract address, that it returns success status and raw data per call, and failure isolation 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?

Three dense sentences with no fluff: network/contract identification, return value disclosure, and usage guidance—every element earns its place.

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

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

Despite lacking output schema, description explicitly documents return format (success status + raw data) and covers network-specific deployment details.

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

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

With 100% schema coverage, baseline is 3; description adds value by explaining the functional impact of allowFailure (preventing batch abort).

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?

Specifically states batching read-only calls via Multicall3 on Ethereum mainnet with contract address, clearly distinguishing from eth_call (single) and mezo_multicall (different network).

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 guidance on allowFailure parameter behavior, though could more explicitly state when to choose this over eth_call (batching vs single call).

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?

Adds return value format ('hex-encoded return data') beyond annotations; reinforces readOnlyHint with 'without sending a transaction'; no contradictions.

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

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

Three sentences, all high-value: action definition, return format, and usage context; front-loaded with specific action; no verbosity.

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?

Explains return values (compensating for missing output schema) and Mezo-specific context; minor gap in explicitly differentiating from eth_call sibling despite implicit distinction via naming.

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 has 100% description coverage establishing baseline; description adds no parameter-specific semantics but doesn't need to given complete schema documentation.

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

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

Specific verb ('Execute') + resource ('read-only smart contract call on Mezo') clearly distinguishes from eth_call sibling by naming the chain and from write operations by emphasizing 'read-only'.

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?

Explicitly states when to use ('read contract state without sending a transaction') but lacks explicit comparison to sibling eth_call for chain selection 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?

Adds critical behavioral detail beyond annotations: explicitly states 'no RPC call needed' and 'Pure computation', clarifying that unlike mezo_call or eth_call, this operates entirely locally without blockchain interaction despite being Mezo-specific.

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?

Extremely concise two-sentence structure where every clause earns its place: first sentence defines the core function, second sentence delivers crucial behavioral constraints and usage context without redundancy.

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

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

Given the simple 2-parameter schema with no output schema or nested complexity, the description fully covers necessary context: what it does, key behavioral trait (pure computation), and input provenance (transaction input or eth_call).

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

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

With 100% schema description coverage already defining 'calldata' and 'abi' precisely, the description adds minimal semantic value for parameters (just referencing 'hex calldata'), meeting the baseline for well-documented schemas.

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?

Clearly states it decodes calldata into function name and typed arguments using a provided ABI, specifically distinguishing it for 'Mezo' (differentiating from eth_decode_calldata) and noting it requires no RPC call (differentiating from mezo_call).

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 clear context on when to use it ('Pure computation', 'Pass the hex calldata from a transaction input or eth_call') but lacks explicit 'when not to use' guidance vs sibling alternatives like eth_decode_calldata.

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?

Adds 'pure computation — no RPC call needed' beyond readOnly annotation, clarifying local execution behavior 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.

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

Three tight sentences: purpose declaration, behavioral constraint, and input source—no redundancy, well front-loaded

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?

Explains transformation output (named fields) despite missing output schema, covers Mezo-specific context adequately for tool selection

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

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

Schema has 100% coverage (baseline 3); description adds minor context about input source (transaction receipt) but no additional parameter semantics

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

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

Specific verb (decode) + resource (event log) + network context (Mezo), clearly distinguishes from eth_decode_log sibling

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?

Specifies input source (transaction receipt log entry) and 'no RPC call needed' to differentiate from call methods, but lacks explicit comparison to eth_decode_log

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?

Adds valuable operational context beyond the readOnlyHint by explicitly stating 'no RPC call needed,' clarifying this runs locally without network requests.

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?

Two tight sentences with zero fluff: first defines the operation, second states the computational nature; perfectly front-loaded.

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?

Since no output schema exists, mentioning 'into typed values' provides necessary return value context; sufficiently complete given the simple 3-parameter input and clear sibling differentiation.

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

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

With 100% schema description coverage, it meets the baseline; mentions 'ABI and function name' in context but adds no new semantic detail beyond the 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?

Clearly states it decodes raw return data into typed values using ABI/function name on Mezo, distinguishing it from both eth_decode_return (via 'on Mezo') and sibling decoders like mezo_decode_calldata (via 'return 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?

The 'Pure computation — no RPC call needed' line effectively distinguishes this from mezo_call and implies usage for existing data, though it lacks explicit 'use when' 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?

Adds valuable traits beyond annotations: specifies 'Pure computation — no RPC call needed' (aligns with readOnlyHint), and enumerates handled revert types (Error, Panic, custom, silent).

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?

Front-loaded with core action; four dense sentences cover purpose, capabilities, behavioral traits, and usage instructions without redundancy.

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

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

Comprehensive coverage of decode capabilities and input sources; lacks output format description but no output schema exists to require it.

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?

Despite 100% schema coverage, adds crucial semantic context about where to source revert_data ('transaction receipt or eth_call error response') and confirms ABI requirement for custom errors.

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?

Specific verb+resource ('Decode raw EVM revert data'), explicitly scopes to Mezo operations, and distinguishes from eth_decode_revert sibling by mentioning 'mezo_call' and 'on Mezo'.

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?

Clearly indicates usage context (failed transactions/mezo_call) and data sources (transaction receipts/eth_call errors), but lacks explicit comparison to eth_decode_revert alternative.

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?

Adds valuable context beyond annotations: discloses raw return data format, specific Multicall3 contract address, and batch failure mechanics (allowFailure 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?

Extremely concise two-sentence structure with no filler; front-loaded with purpose and immediately followed by critical usage guidance.

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?

Adequately compensates for missing output schema by describing return values (success status and raw data); covers essential behavioral aspects of batching.

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% so baseline applies; description adds minimal new semantics for inputs but clarifies allowFailure's impact on batch execution.

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?

States specific action (batch read-only calls), identifies the chain (Mezo) and contract (Multicall3 at 0xcA11...), distinguishing it from eth_multicall and single-call 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?

Provides concrete guidance on allowFailure parameter usage, but lacks explicit comparison with sibling tools (e.g., when to use vs mezo_call or eth_multicall).

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