Contract Powers

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states what is returned (contract type, verification, name, proxy status, counts, owner presence) and what is withheld (decision fields listed by name). It calls itself a 'free preview,' indicating partial information. This is transparent about the operation's behavior and limitations.

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 efficiently structured in three sentences: the first establishes scope and purpose, the second lists return fields, and the third provides usage routing. It is front-loaded with the most critical information and contains no fluff. Every sentence adds 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?

For a tool with only 2 parameters and no output schema, the description comprehensively explains what the agent will receive (return fields), what is intentionally omitted (decision fields), and when to use an alternative. Nothing essential is missing for an agent to correctly invoke this tool and interpret results.

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%, with each parameter already described ('Default base.' for chain, '0x-prefixed 20-byte address.' for address). The tool description does not add further parameter-level semantics beyond the schema; it only contextualizes the overall purpose. Thus the baseline of 3 applies, as the schema already handles parameter 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?

The description clearly states the tool's purpose: 'Free preview for ANY verified EVM contract on base, ethereum or polygon — including addresses not in the registry.' It specifies the resource (verified EVM contract), the scope (three chains), and mentions the extension beyond the registry. It distinguishes itself from get_contract_powers by noting the preview nature and withheld decision fields.

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?

Explicit guidance is given: 'Use get_contract_powers first if the contract is already in the registry — that is free and complete.' This directly tells the agent when to use this tool versus the sibling. It also implies this tool is for contracts not in the registry or for a quick preview, covering both when and 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?

With no annotations, the description carries full behavioral disclosure. It openly details what the analysis returns, including evidence/confidence, reachable DELEGATECALL/SELFDESTRUCT/CREATE2 opcodes, and uncategorized owner-only functions, plus the 'free' nature. This goes beyond a simple 'reads data' and sets clear expectations about the depth and limitations of the analysis.

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 dense sentence that lists numerous outputs in an organized, parenthetical-heavy structure. It has no filler and front-loads the key purpose ('Full free analysis'), but the length and dense enumeration make it slightly less scannable than a shorter, bulleted version.

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 read-only analysis tool with no output schema and no annotations, the description is remarkably complete. It covers input format, all major output categories, the confidence/evidence aspect, and even mentions the uncategorized functions where unusual powers hide. An agent can predict exactly what it will receive and what constraints apply.

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 description adds only a reiteration of the contract parameter format ('address or a symbol such as USDC'). It does not explain nuances like symbol resolution or chain ambiguity beyond what the schema already contains, so it provides baseline value only.

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 ('Full free analysis') and enumerates the exact resource and outputs: verification, proxy pattern, implementation address, admin key type, retained powers with evidence/confidence, reachable dangerous opcodes, and uncategorized owner-only functions. This clearly distinguishes it from siblings like list_watched_contracts and recent_power_changes, which target different 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 states the tool operates on 'one contract that is in the registry' and accepts an address or symbol. This gives strong contextual guidance on when to use it. However, it does not explicitly name alternatives or state when not to use it (e.g., for contracts not in the registry), leaving some routing 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?

No annotations are provided, so the description carries the burden. It discloses the output shape (one-line risk shape with four specific attributes) and that filters combine with AND. However, it doesn't disclose pagination behavior, rate limits, or what happens when no contracts match. The description adds meaningful behavioral context but leaves some operational details uncovered.

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 with no waste. The core purpose and output shape are front-loaded, the usage guidance is in the second sentence, and the filter semantics are in the third. Every sentence 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?

For a list tool with no output schema, the description adequately explains what the return contains (one-line risk shape with four attributes). It doesn't mention pagination or result limits beyond the schema's 'limit' parameter, but the tool is simple enough that the description is nearly complete. The missing operational details (pagination, empty results) 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 description coverage is 100%, so the schema already documents all four parameters. The description adds the AND-combination semantics for filters, which is useful beyond the schema. However, it doesn't add detail about the 'limit' default behavior or the exact meaning of 'upgradeable' beyond what the schema says. Baseline 3 is correct because the schema does the heavy lifting and the description adds only marginal filter 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?

The description states a specific verb ('List'), a specific resource ('EVM contracts in the Contract Powers registry'), and the exact risk-shape fields returned. It clearly distinguishes itself from siblings by focusing on the registry listing with risk summaries, not a single contract lookup or power changes.

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 'Use this to see what is already analysed before spending a lookup,' which gives clear context for when to use it. It doesn't explicitly name alternatives or exclusions, but the sibling names and the listing-vs-lookup distinction imply when not to use it. A 4 is appropriate because the usage context is clear but no explicit alternative routing is given.

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 provided, the description carries the full behavioral disclosure burden. It does disclose important traits: each event carries before/after values, the detection window, and a severity level. However, it does not mention sort order, pagination behavior, read-only guarantees, or any permissions/rate-limit considerations.

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 compact sentences, each earning its place: the first frames the tool, the second describes returned event fields, the third defines severity, and the fourth gives the usage trigger. It is front-loaded and free of 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?

There is no output schema, so the description should explain return values; it does by listing before/after values, detection window, and severity. All parameters are optional and covered by the schema. Minor missing details like default ordering or how filters combine do not prevent correct selection and 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?

Schema coverage is 100%, so the baseline is 3. The description adds no deeper meaning beyond what the input schema already contains; it mentions severity levels, but the enum in the schema already documents that.

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 what the tool reports ('what actually changed behind the watched contracts') and gives concrete event types: implementation swapped, owner moved, power appeared/disappeared, verification lost. This specific scope distinguishes it from siblings like get_contract_powers or check_any_contract, which focus on current state or general checks.

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 explicitly provides a natural-language trigger: 'Use this to answer "has anything changed behind this contract recently?"' and scopes the tool to watched contracts. It does not explicitly name alternatives or exclusions, but the usage context is clear enough for an agent to select it.

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