Base Web3 M2M Hub

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds real value beyond them: the per-call cost (0.0030 USDC, first free) and an explicit bound on what the result does and does not cover (not a security audit). It does not mention rate limits or failure modes, keeping it short of 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?

Two tight sentences front-loaded with the core capability, followed by the scope disclaimer and the pricing detail. Every clause carries information, though the pricing could arguably be split into its own clearly-labeled clause.

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 carry the return-value burden, and it does: bytecode size, proxy detection details, and owner(). Combined with annotations covering safety and the explicit cost and scope caveats, an agent has everything needed to select and call 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% for the single address parameter, so the schema already documents it fully. The description adds the important context that the address is expected on Base, which is marginally useful beyond the schema's generic "Address (0x...)" wording, matching the baseline 3 for high-coverage 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?

The description names a specific verb and resource ("Technical profile of a contract on Base") and enumerates the exact outputs: bytecode size, proxy detection (EIP-1167/EIP-1967 implementation and admin), and owner(). The explicit "This is NOT a security audit" cleanly separates it from sibling tools like token-due-diligence.

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 "NOT a security audit" disclaimer scopes when this tool is appropriate and implicitly routes audit needs elsewhere, and the price/free-first-call note gives an invocation condition. It stops short of naming an explicit alternative tool, so it is clear context rather than full when/when-not routing.

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 and openWorldHint, so safety is covered; the description adds genuinely non-structured context: the exact cost per call (0.0050 USDC, first free), the scope of what is excluded (fees, gas, slippage), and the precision of the returned spread. It stops short of rate limits or latency, which keeps it off 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 that are front-loaded with the core action, then the exclusions, then the price. No filler, and each sentence carries distinct decision-relevant 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?

No output schema exists, and the description compensates by naming the return fields (gross spread bps, cheaper side) and the supported chain and venues. With a single optional parameter and read-only annotations, this is nearly complete; only error behavior on unsupported pairs and freshness/latency of the quote are unaddressed.

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?

One optional parameter with 100% schema description coverage, so the schema already states that only "WETH/USDC" is supported. The description repeats the pair restriction without adding format, casing, or defaulting semantics, 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?

Names a specific verb (read on-chain spot price) and resource (WETH/USDC on Uniswap v3 and Aerodrome v2 on Base), plus the exact output (gross spread in bps and cheaper side). An agent can tell precisely what this returns without opening the schema, and no sibling tool overlaps it.

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 rather than stated: the tool is evidently for screening arbitrage spreads, and the caveat that fees, gas and slippage are excluded implicitly signals it is a pre-trade screen, not a profitability calculation. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling for the follow-up cost analysis.

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 and openWorldHint, so the safety profile is covered; the description adds genuinely useful context beyond them: the data source (Aave v3 on Base, read on-chain) and a metered cost (0.0050 USDC per call, first free). It does not disclose behavior for unlisted assets or failure modes, keeping it short of 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?

Two tight sentences, front-loaded with protocol, chain, and returned data, followed by the pricing constraint. No filler, and every clause carries information the 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?

For a single-optional-parameter read tool with no output schema, the definition covers source, scope, default, and cost adequately. It could still say what happens for an unlisted asset or give units/format for the fee, which is why it is not a 5.

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 one optional parameter and 100% schema description coverage, the schema already documents asset as an ERC-20 address defaulting to WETH. The description only restates the default asset value, adding no format or edge-case detail beyond the schema, 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 resource (flash-loan liquidity and fee), the protocol (Aave v3), the chain (Base), and the access mode (read on-chain). An agent can instantly tell this returns flash-loan data rather than anything in the sibling set (contract-profile, dex-arbitrage, liquidity-health, etc.).

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 description makes clear it returns liquidity/fee data, so the agent can infer it is used when sizing or pricing a flash loan, but there is no explicit when-to-use, no prerequisites, and no alternative named among the 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the upstream source (eth_feeHistory), data freshness (live), the averaging window (10 blocks), units (gwei), and a per-call price with a free first call. Rate limits, caching, or failure behavior for the paid endpoint are not disclosed.

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 waste, and front-loaded: the payload is stated first, the cost second. Every clause carries information an agent needs to decide and to predict the response.

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 usefully enumerates the returned values and their units, plus the data source, freshness, and price. It could go further on what the congestion label's values mean and whether fields can be absent, but for a zero-parameter read-only feed it is nearly complete.

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 tool takes zero parameters, so the 4 baseline applies; there is nothing to disambiguate. The description instead documents the return fields, which is a bonus rather than a parameter 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?

States the resource (live Base Mainnet gas data) and enumerates exactly what is returned: latest and 10-block average base fee in gwei, p25/p50/p75 priority-fee percentiles, and a congestion label. It is plainly distinct from every sibling (contract-profile, dex-arbitrage, whale-wallet-tracker), though it never names or contrasts a sibling, keeping it 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?

Usage is only implied: an agent can infer it is the go-to source for gas pricing when timing or costing a Base transaction, but there is no explicit when-to-use statement or reference to alternatives. The cost note (0.0020 USDC, first call free) is useful call-planning context but is not usage guidance per se.

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 and openWorldHint, so the safety profile is covered; the description adds real behavioral context by disclosing the per-call price (0.0050 USDC, first call free) and the exact risk-band classification scheme the agent will receive. It stops short of explaining data freshness or how the band thresholds are computed.

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?

One dense sentence, front-loaded with protocol and chain, then output fields, then pricing — nothing wasted. It is slightly run-on with the enumerated band list and price clause packed in, but 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?

With no output schema, the description carries the return-value burden and does so by listing collateral, debt, health factor and the five band values. Missing only secondary details such as threshold definitions or data recency, which keeps it from being fully complete for a priced, real-time risk tool.

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?

Only one parameter exists and schema description coverage is 100%, so the schema already documents userAddress. The description adds marginal value by implying any wallet address works ('for any wallet'), but no format or ownership caveats beyond the schema's 0x 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+resource scope: Aave v3 on Base, returning total collateral, debt, health factor and a named risk band for a wallet. The protocol and chain qualifiers distinguish it from generic siblings like liquidity-health or whale-wallet-tracker, and the enumerated output fields make the tool's remit unambiguous.

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 never says when to reach for this tool versus alternatives such as liquidity-health or whale-wallet-tracker, and gives no prerequisites beyond 'any wallet'. Usage is only implied by the topic; no exclusions or competing-tool routing are offered.

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 the safety profile (readOnlyHint, openWorldHint), and the description adds real context on top: the external data provider, the on-chain facts returned, a per-call price of 0.0050 USDC with the first call free, and an explicit disclaimer of any safety verdict. It stops short of describing latency, caching, or failure 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 compact sentences, front-loaded with purpose before evidence source, caveat, and price. The parenthetical flag list is dense but each item is informative; nothing is 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?

For a read-only, one-parameter lookup with no output schema, the description supplies what the agent needs: what is returned, where the data comes from, what it costs, and the limits of what the result proves.

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?

There is a single parameter with 100% schema description coverage that already specifies 'ERC-20 token contract address (0x...) on Base'. The description's mention of Base and ERC-20 merely echoes the schema, adding no syntax or format 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?

States a specific resource (risk flags for an ERC-20 on Base) plus the concrete data source (GoPlus + on-chain facts) and enumerates the flag categories, so an agent can distinguish it from siblings like contract-profile or token-deploy-radar without opening a 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 implied — reach for this when you need pre-trade risk signals on a Base token — and the caveat 'no safety verdict: no flags is not a guarantee' usefully frames interpretation. However, it never names an alternative tool or states when NOT to use this one, leaving 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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful context beyond them: per-call pricing (0.0050 USDC, first call free) and an important risk caveat that a new pool does not imply a legitimate token. However, it omits how far back the scan reaches behaviorally and any rate-limit 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?

Three tight sentences with zero waste, front-loading what the tool returns before the caveat and cost. 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 read-only tool with complete parameter documentation and no output schema, the description compensates by naming the returned fields and disclosing cost and a risk caveat. It is close to complete, missing only any note on scan-window behavior or result freshness.

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 both limit and windowBlocks with defaults and ranges. The description adds no parameter syntax or meaning 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 resource and scope: newest Uniswap v3 pools created on Base via PoolCreated events, with returned fields (token symbols, fee tier, block). The purpose is concrete enough to distinguish it from most siblings, though it never names the closest alternative (token-due-diligence) 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?

The description hints at the use case (finding freshly created pools) but gives no explicit when-to-use, when-not-to-use, or alternative routing. It does not tell the agent when to reach for this versus token-due-diligence or liquidity-health.

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), and the description adds genuinely new behavioral context: a per-call price (0.0100 USDC, first call free) and the expectation-setting 'Returns objective signals, not a verdict.' That pricing detail is the kind of thing annotations cannot convey. It stops short of noting rate limits or what happens on an unsupported token.

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 dense, front-loaded sentence names the scope and the three data sources, followed by two short sentences for the output stance and pricing. Every sentence earns its place with 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?

With no output schema, the description carries the return-value burden and does so by naming the three signal categories returned (risk flags, on-chain facts, pool liquidity in USD). Combined with pricing and the read-only annotation, an agent has everything needed to call 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?

Only one parameter with 100% schema description coverage, so the schema already documents the tokenAddress format (ERC-20, 0x..., on Base). The description adds no syntax or constraint detail beyond that, making the baseline 3 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?

States a specific verb+resource (due diligence for an ERC-20 on Base) and enumerates exactly what is aggregated: GoPlus risk flags, on-chain facts (supply, owner, proxy), and Uniswap v3 pools vs WETH/USDC. The 'Replaces three separate calls' line lets an agent distinguish it from siblings like contract-profile and liquidity-health 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?

The 'one-call' framing plus 'Replaces three separate calls' gives a clear signal that this is the consolidated entry point rather than the narrower sibling tools. However, it never states an explicit when-not-to-use case or names the siblings it supersedes, so routing still requires a small 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-schema context: a per-call price of 0.0050 USDC with the first call free, and that results come from confirmed Transfer logs. It stops short of noting latency or rate limits beyond the implicit ~2s/block.

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 dense sentence with zero filler: scope first, then returned fields, then cost. Every clause 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?

With no output schema, the description correctly enumerates the return fields (amount, sender, receiver, tx hash, block) and discloses pricing, which is what an agent needs to decide and call. It lacks guidance on what counts as a 'whale' threshold beyond the schema default and has no sibling routing.

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 windowBlocks and minUsdcAmount are already documented with ranges and defaults. The description only restates the ~300 default, adding no new syntax or trade-off guidance beyond the 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?

States a specific resource (large USDC transfers), chain (Base), scope (most recent blocks, default ~300) and data source (confirmed Transfer logs), so an agent can immediately tell it apart from siblings like liquidation-monitor or token-deploy-radar. The returned fields are enumerated, making the tool's output shape unambiguous.

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 purpose implies a whale-monitoring use case, but the description never states when to pick this over related siblings (e.g. token-due-diligence or liquidity-health) or any preconditions/exclusions. Usage is left to inference from the resource description alone.

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