ContractLens

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the shape of the answer (classification categories plus native balance) and implies a non-mutating lookup, which is useful. But it says nothing about chain coverage, what is returned for an unknown/unfunded address, or any permission/rate constraints.

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, zero filler. The classification list and the usage trigger each earn their place, and the actionable instruction is front-loaded after the core identification content.

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 no output schema, the description does the work of naming the return categories an agent should expect, which is the key gap for a lookup tool. It falls short only on unknowns — error/unknown-address behavior and supported chain scope are unstated.

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% and both parameters ("0x address", "EVM chain id") are documented in the schema, so baseline is 3. The description adds no format, casing, checksum, or chain-range detail beyond what the schema already states.

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

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

The description states a specific question it answers ("What is this address?") and enumerates the concrete classifications it resolves: EOA, EIP-7702 delegated EOA, Safe multisig with threshold/owners, timelock, ERC-20 token, proxy or contract. This is specific enough to separate it from sibling check_token and scan_contract without opening either schema.

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 an explicit trigger condition: "Use before sending funds to or trusting an address." That is real when-to-use guidance tied to a concrete risk decision. It does not, however, name any alternative (e.g. when scan_contract or check_token would be the better call), so routing between siblings is left to inference.

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 and does well: it discloses latency (1-3s), the output form (LOW/MEDIUM/HIGH with reasons), and the full scope of analysis. It stops short of stating side effects/auth needs, but as a read-style analysis tool the behavioral profile is largely conveyed.

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-loads the payoff (fast risk verdict) and then lists the dimensions checked and supported chains without filler. Dense but every clause earns its place for an agent deciding whether to call.

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?

There is no output schema, so the description correctly explains the return shape (verdict tier plus reasons). Combined with supported chains and check dimensions, an agent has everything needed to invoke it 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 coverage is 100% so the baseline is 3, but the description adds real meaning by mapping supported chain IDs to networks (1 Ethereum, 8453 Base, etc.), which directly informs the chainId parameter beyond the schema's bare 'EVM chain id' note.

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 a specific verb (risk verdict) and resource (ERC-20 token) and enumerates exactly what it checks: ownership control, proxy upgradeability, admin powers, source verification, and liquidity. This differentiates it clearly from generic siblings like scan_contract or address_info, letting an agent pick it without opening the schema.

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?

Gives clear activation context ('before buying it'), which tells the agent when this tool applies. However, it never names an alternative (e.g., scan_contract for a general contract scan) or states exclusions, so routing between siblings still requires inference.

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 and does well: it discloses that a real payment is attempted, that the signing key is fresh and unfunded (so no funds are at risk), that the request traverses both the server and facilitator, and it enumerates the exact failure classes reported (schema, description length, EIP-712 domain, price cap, paywall enforcement). It does not state network side effects, rate limits, or whether the endpoint is mutated, which is the remaining gap.

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, front-loaded with the audience and the core question, followed by a dense but earned enumeration of failure reasons. No filler.

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?

Single required parameter, no output schema, so the description must convey what comes back – it does by listing the exact reasons reported on non-payable endpoints and stating that payable ones fail only on balance. Missing only the shape of the success response and whether the probe has side effects on the endpoint's state.

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% for the single 'url' parameter, so the schema already documents format expectations. The description adds no syntax, encoding, or constraint detail beyond it, so the baseline of 3 applies.

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?

Names a specific action (send one signed payment from a fresh unfunded key through the endpoint's server and facilitator) against a specific resource (an x402 endpoint) and states the diagnostic question it answers. It is unmistakable against chain-data siblings like scan_contract or gas_now.

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 'For x402 sellers' framing and the 'can a real buyer actually pay this endpoint?' question make the use context clear, and the failure enumeration implies it is a pre-publication validation step. No explicit exclusions or sibling alternatives are given, but the siblings are unrelated domains so none are needed.

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 behavioral burden. It discloses the shape of the output and the word 'Live' implies a real-time network fetch rather than cached data, but it omits rate limits, latency, failure modes on unsupported chains, and any auth requirements. For a low-risk read operation this is adequate but leaves clear gaps.

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 dense sentences with zero filler, front-loading the core subject and following with the supported-chain constraint. Nothing could be removed without losing 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 no output schema, the description must describe return values, and it does so concretely (base fee, tiered tips, maxFeePerGas, action costs) for a one-parameter tool. The only real gap is behavior on an unsupported chainId and freshness guarantees, which are minor for this tool's complexity.

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% and the single parameter is documented with an example (8453 for Base), so the baseline would be 3. The description adds genuine value the schema lacks: an enumerated allow-list of supported chain ids (1, 8453, 42161, 10, 137, 56) that the schema does not express as an enum, preventing calls to unsupported chains.

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 names a specific resource (live EIP-1559 gas per chain) and enumerates exactly what the response contains: base fee, slow/standard/fast tips, maxFeePerGas, and action costs. This is unmistakably distinct from the sibling tools (address_info, check_token, check_x402_payability, scan_contract), none of which deal with gas pricing.

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 by the enumerated return values and the explicit list of supported chains, which functions as an implicit constraint on the chainId argument. However, there is no statement of when to prefer this tool, no guidance for unsupported chains, and no mention of alternatives for historical or non-EIP-1559 gas data.

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 behavioral burden and does well: it discloses the prerequisite scope (contract must be verified), the exact categories of findings returned, that findings are ranked by impact, and that ownership control is classified (renounced / EOA / Safe multisig). It omits failure behaviour for unverified contracts and any cost, latency or rate-limit context, so it is strong but not exhaustive.

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?

Purpose and returned artefacts are front-loaded in the first sentence, the usage trigger follows, and the compact chain list closes it out. Dense but every clause earns its place; nothing is redundant.

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 no output schema and no annotations, the description compensates well by describing the return contents and ranking. What remains missing is the behaviour when a contract is unverified or the scan fails, and whether results are paginated or time-bounded, which matters for a scan tool an agent may call speculatively.

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 the baseline is 3, and the description adds genuine value by enumerating the supported chain IDs (1, 8453, 42161, 10, 137, 56), which materially constrains and validates the otherwise open-ended chainId parameter. The Sourcify verification requirement reinforces the address parameter's constraint.

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 (security scan) plus precise resource (verified EVM smart contract) with an explicit enumeration of what is returned: ownership control, owner/role-gated functions, proxy status, and Slither findings. It is clearly distinguishable from siblings like address_info and check_token by scoping itself to contract-security analysis.

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?

Gives a concrete decision trigger: 'Use before approving, depositing into or buying a token.' That tells the agent the moment of use, but it names no alternatives or exclusions (e.g. what to use for an unverified contract), so it stops short of full when/when-not guidance.

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