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

No annotations are provided, so the description carries the burden. It states the tool analyzes for specific vulnerabilities and gives a security score, but does not disclose whether it returns a detailed report, whether it has limitations (e.g., only certain Solidity versions), or whether any side effects (none expected). Moderate clarity.

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 concise sentence that communicates core purpose and outputs. No fluff, but it lacks a brief note on output specifics that could enhance without much length.

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 two params, no output schema, and no annotations, the description is adequate but not thorough. It explains the audit scope and output score, but does not mention the output format (e.g., JSON report), severity levels, or any limitations, leaving some agent uncertainty.

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 both parameters documented. The description adds that sourceCode must be complete and the target contract is optional, which aligns with the schema. It doesn't need to add much beyond the schema, but does note completeness requirement.

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 specifies the tool audits Solidity source code for specific vulnerability types and generates a security score. It clearly distinguishes from siblings like evm_estimate_gas and evm_decode_calldata, though it lacks explicit comparison to evm_fetch_source.

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

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

The description implies usage for security checking of Solidity code, but provides no guidance on when to use this versus alternatives, prerequisites (e.g., should code be compiled first), or what scenarios warrant this 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?

With no annotations, the description carries the full burden of behavior disclosure. It states what the tool returns (decoded components) but does not mention error handling, input validation, or any side effects. It adds some value by specifying the output structure beyond the schema, but it omits important behavioral details.

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, well-structured sentence that directly states the tool's purpose and outputs. No unnecessary words or repetition, making it highly concise and easy 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?

For a simple tool with one parameter and no output schema, the description provides sufficient context about the operation and expected output. It could be more detailed about the exact format of the decoded segments, but overall it is complete enough for a decode 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 provides 100% coverage for the single parameter 'calldata', specifying it as hex-encoded and starting with 0x. The tool description does not add further semantic meaning to the parameter, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb 'Decode' with a clear resource 'raw EVM transaction calldata' and explicitly lists the output components (function selector, parameter segments, byte length). It is easily distinguishable from sibling tools like evm_estimate_gas or evm_audit_contract.

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

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

The description implies when to use the tool (whenever raw EVM calldata needs decoding) but does not explicitly mention alternatives or exclusion scenarios. The context is clear enough for an AI agent to infer the appropriate use case, but it lacks explicit guidance on when not to use it.

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

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

There are no annotations to rely on, so the description carries the full burden of behavioral disclosure. It mentions 'real-time' and 'telemetry' but does not disclose whether this is a read-only operation, any rate limits, or what happens if the network is unsupported. The description is a bit vague about the exact behavior.

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

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

The description is a single sentence with no fluff. It is concise and front-loaded with the main purpose ('real-time gas price and network execution telemetry'). 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 tool has only one parameter with full schema coverage and no output schema, the description is fairly complete. However, it could be more explicit about the output format or additional telemetry details, but for a simple query tool, it is reasonably sufficient.

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

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

The schema description coverage is 100%, and the parameter 'chain' has an enum with descriptions for each value. Since the schema already explains the parameter, the description adds no extra meaning beyond what's in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool provides real-time gas price and network execution telemetry across supported EVM networks. It distinguishes itself from siblings like evm_audit_contract, evm_fetch_source, and evm_decode_calldata by focusing on network-level telemetry rather than contract or transaction 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 description implies usage for querying gas prices and telemetry, but it does not explicitly state when to use this over alternatives or provide exclusions. Given the sibling tools are quite different, the context is somewhat clear, but explicit guidance is missing.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. It does convey that this is a read-only fetch from block explorers and that the source must be verified, which is minimally viable. However, it does not describe failure behavior, return format, or external dependencies like API rate limits.

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

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

A single, front-loaded sentence that immediately states the operation and scope. Every word earns its place, and there is no padding 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?

For a simple two-parameter read operation, the description is largely complete: it names the resource, the chain family, and the source of data. Minor gaps remain because there is no output schema and no mention of BSC, but the schema covers the chain enum and the operation is straightforward.

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

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

Schema description coverage is 100%, so the input schema already documents both parameters and the chain enum. The description adds no additional parameter-level meaning and even omits BSC from the chain list, though the schema includes 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?

Description uses a specific verb ('Fetch') and a specific resource ('verified smart contract source code'), and names the supported chains. It also clearly distinguishes the tool from sibling tools that estimate gas, audit contracts, or decode calldata.

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 no explicit guidance on when to choose this tool over alternatives, nor does it state prerequisites or exclusions. Usage context is only implied by the tool name and the phrase 'verified smart contract source code.'

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