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

Annotations already declare the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the bar is lower. The description adds genuinely useful behavior beyond that: a paid, x402-gated operation costing 1.00 USDC on Base, which an agent must know before invoking. It stops short of explaining the payment/result flow.

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 tightly packed sentences with zero filler: identity, function, and the gating requirement, in that order. Nothing is wasted and the most decision-relevant constraint is not buried.

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?

An output schema exists so return values need no explanation, and annotations carry the safety profile, so the description only needs purpose, cost, and preconditions, which it covers. The one gap is sibling differentiation against contract.auditTeaser, which the agent cannot resolve from this description alone.

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 contractAddress, paymentHash, and referralWallet are all self-documented in the schema, and the referral kickback is explained there in detail. The description adds no parameter-level meaning beyond naming the x402 protocol, so baseline 3 is correct.

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 and resource: audits Base smart contracts for vulnerabilities, with the added qualifier that it is an AI-driven live auditor. It is clear what the tool does, but it never distinguishes itself from the sibling contract.auditTeaser, leaving the agent to infer the difference on its own.

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 surfaces a real prerequisite (a 1.00 USDC payment via x402), which is useful invocation context, but gives no when-to-use guidance relative to alternatives like contract.auditTeaser or token.analyze. Usage is implied rather than stated or bounded.

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 cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description only needs to add beyond that. It does disclose an important behavioral trait: results are deliberately obscured to upsell, so the agent knows not to expect complete vulnerability details. It doesn't note any rate limits or auth requirements, which keeps it below a 5.

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 short sentences, front-loaded with what the tool is and what it returns. Minor redundancy between 'Free teaser' and the trailing 'Free to use', which costs it the top score.

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 an output schema present, return-format detail isn't required, and the description covers purpose, cost, and the deliberate obscuring of results. It's nearly complete for a one-parameter read tool; only the explicit relationship to contract.audit is left implicit.

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 there is a single documented parameter (contractAddress on Base network), so the schema carries the semantics. The description adds nothing about the parameter, matching the baseline 3.

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 resource (smart contract auditor) and a precise scope: a free teaser returning vulnerability counts. It implicitly contrasts with the paid sibling contract.audit, so an agent can differentiate without opening any 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?

Explains the context clearly (free, teaser, upsell-oriented) and references the paid audit as the fuller alternative, but never gives an explicit when-to-use rule like 'use this only for a quick triage before calling contract.audit'.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is largely covered. The description adds genuinely new behavioral context by disclosing the 5.00 USDC x402 payment requirement, which is an auth/cost constraint the annotations do not carry. It stops short of explaining the payment-then-patch flow, but the added cost gate is real value.

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 short sentences, front-loaded with the core purpose and followed by the differentiator and the payment requirement. 'Premium' is marketing filler, but otherwise every sentence carries 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description supplies the payment prerequisite, though it omits the concrete x402 payment steps an agent would need before it can produce a valid paymentHash. Nearly complete 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 contractAddress, paymentHash, and the optional referralWallet kickback are fully documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 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?

States a specific verb (patch/rewrite) and resource (vulnerable Solidity smart contract code), and explicitly distinguishes itself from the sibling contract.audit with 'Not only audits but rewrites.' An agent can tell what it does and how it differs from the audit family without opening any 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?

Usage is only implied: the contrast with contract.audit suggests using this tool when you want remediation, not just a report. There is no explicit when-to-use/when-not guidance and no statement of what happens if you only need an audit, so the agent must infer the routing decision.

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 only declare readOnlyHint and openWorldHint; the description adds valuable behavior beyond them: the call is metered, costs 0.10 USDC, and settles via the x402 protocol. It still omits operational details such as latency, rate limits, or failure behavior when payment is missing, so it is not fully transparent.

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 short sentences with the routing behavior front-loaded, but the opening fragment 'Agent-to-Agent Compute Arbitrage.' communicates nothing actionable and arguably does not earn its place. The remaining two sentences are dense and useful.

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?

An output schema exists, so return values need no explanation, and both parameters are covered. However, the description never explains how an agent obtains the required `paymentHash` before calling, which is a real procedural gap for a tool whose only optional parameter is gated behind an out-of-band payment.

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 both `prompt` and `paymentHash` are already documented in the schema; the description adds only the surrounding context of the x402/Base payment that the schema itself already states. Baseline 3 is appropriate when the schema does the heavy lifting.

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 second sentence gives a concrete verb and resource: 'Route raw LLM prompts to our Gemini instance,' which is specific enough to separate it from siblings like token.analyze or contract.audit. The leading slogan 'Agent-to-Agent Compute Arbitrage' adds branding rather than meaning, and no sibling is named as an alternative.

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 states a hard prerequisite (a 0.10 USDC micro-transaction over x402), which is real usage context, but it never says when to prefer this tool over the sibling compute/analysis tools or when not to use it. Usage is only implied by 'route raw LLM prompts.'

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 cover readOnlyHint and openWorldHint, but the description adds information the annotations do not: a hard price (10.00 USDC) and the fact that access is gated on an external payment. It does not explain what happens with an invalid/reused/expired payment hash, and the word 'Purchase' sits in mild tension with readOnlyHint=true even though the payment itself happens outside the tool.

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 short sentences, with the capability stated first and the cost prerequisite second. No filler or repetition; every sentence carries information an agent needs.

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 an output schema present, return values need not be described, and the description covers purpose and the payment gate. It leaves open operational questions for a paid, open-world call (payment freshness/one-time use, how fresh the 'right now' data is), but nothing essential to invoking the tool correctly is missing.

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 paymentHash description already specifies the amount (10.00 USDC) and chain (Base), so the description adds no new parameter-level detail beyond restating the price. Baseline 3 is appropriate when the schema carries the 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?

States a concrete verb ('Purchase') and a concrete resource ('aggregated intelligence on which contracts and wallets other AI agents are analyzing right now'), which is clearly distinct from siblings like contract.audit, wallet.profile, or token.analyze. It stops short of naming or contrasting an alternative sibling, and 'aggregated intelligence' is a slightly fuzzy abstraction of what is actually returned.

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 only usage-relevant content is the cost prerequisite ('Requires 10.00 USDC') plus the 'right now' framing implying recency-sensitive use. There is no statement of when to prefer this over siblings such as contract.audit or wallet.profile, and no when-not conditions, so usage must be inferred.

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 annotations already indicate readOnly and openWorld behavior. The description adds a useful behavioral detail: a 0.01 USDC micro-transaction is required. However, it does not clarify the payment flow, whether paymentHash must be supplied, or what happens if payment is missing.

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 short sentences with the key resource and cost front-loaded. There is no wasted language.

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?

An output schema exists, so return values need not be described. However, for a paid retrieval tool, the description leaves the payment mechanics unclear, especially because paymentHash is not required in the schema despite the description saying a micro-transaction is required.

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 both parameters are already documented in the input schema. The description does not add parameter-level meaning beyond noting the payment cost, which is consistent with the baseline of 3 when 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 a specific verb and resource: retrieving stored context or data from an agent memory bank. It distinguishes itself from memory.store by using 'retrieve', though it does not explicitly name or compare against that 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?

The description states the tool's purpose and cost but gives no guidance on when to use it versus alternatives such as memory.store or other retrieval tools. There are no usage conditions or exclusions.

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 only say readOnlyHint=false and openWorldHint=true; the description adds the genuinely useful behavioral fact that a 0.01 USDC micro-transaction is required, which the schema alone would not surface. It stops short of stating whether the payment is per-call or per-key, or what happens on key collision.

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 short sentences, action first and cost second, with no filler. The 'Agent Memory Bank:' prefix is mildly redundant given the tool name but costs little.

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?

Output schema exists so return values needn't be explained, and the cost is disclosed. However, for a mutating store operation it omits key-collision/overwrite behavior and payment lifecycle, leaving real gaps an agent would care about.

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 memoryKey and memoryValue are already fully documented in the schema. The description reinforces the payment requirement behind paymentHash but adds no format, constraints, or collision semantics. Baseline 3 applies when the schema does the heavy lifting.

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 and resource: store arbitrary context/snippets/vectors persistently in an agent memory bank. An agent can distinguish it from the sibling memory.retrieve without opening the schema, though the description never names that sibling explicitly.

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 when-to-use guidance, no conditions for choosing this over alternatives, and no exclusions. Usage must be inferred entirely from the name and the store/retrieve pairing.

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 cover the safety profile (readOnlyHint, openWorldHint), so the description is free to add the non-obvious behavior it does: this is a paid 'premium' tool requiring a USDC payment on Base. That cost disclosure is genuinely valuable context beyond annotations. It still omits failure behavior when the payment hash is invalid or insufficient, keeping it out of 5 territory.

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 tightly packed sentences: the first states purpose and scope, the second states the cost. Nothing is wasted and the critical payment requirement is front-loaded rather than buried.

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 an output schema present, return values need not be explained, and the description covers chain, data categories, and cost. The one gap is the payment workflow: it never says how to obtain the required paymentHash or what happens if payment validation fails, which an agent needs for a paid endpoint.

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 all three parameters are already documented in the schema, including the purpose of paymentHash and the optional referralWallet kickback. The description adds only the chain context ('on Base'), so the 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 names a specific verb-plus-resource: real-time analytics (liquidity, volume, smart-money) for any Base token. An agent immediately knows what data it returns and on which chain. It does not distinguish itself from the likely sibling market.alpha, so it stops short of a 5.

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 discloses the crucial precondition that usage costs 0.50 USDC, which is real gating information for deciding whether to call it. However, there is no explicit when-to-use statement and no comparison or routing guidance against siblings like market.alpha or contract.audit.

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 declare readOnlyHint=true and openWorldHint=true, and the description is consistent with a read-only analysis. It adds meaningful context beyond the annotations by disclosing a hard cost (2.00 USDC) and the x402 payment protocol, though it omits practical consequences such as what happens if payment or paymentHash is missing.

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 short sentences, front-loaded with the core capability and payment requirement. The 'Smart Money Oracle' branding is mildly decorative and adds no routing value, but nothing is padded.

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?

An output schema exists so return values need no explanation, and the cost is disclosed. However, for a paid x402 tool the payment workflow is underspecified: it never says whether paymentHash is required on the first call, how to obtain it, or what error surfaces on non-payment, which an agent needs to invoke this 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 both parameters (paymentHash and targetWallet) are already documented in the schema and the baseline is 3. The description restates the payment requirement but adds no syntax, sequencing (pay-then-pass-hash), or format detail beyond what structured fields provide.

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 and resource: it analyzes a wallet's on-chain behavior and produces a psychological risk profile, which is cleary distinguishable from siblings like token.analyze and contract.audit that operate on different subjects. The scope is explicit enough that an agent can route to 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?

Usage is only implied by the resource type (wallet), with no guidance on when to prefer this over market.alpha or contract.audit, and no exclusions. The one genuine usage constraint it does give is the payment prerequisite, which is useful but not a use-case rule.

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