onchaincheck

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

With no annotations, the description carries the full burden and does so: it discloses the return content on match (entity, programs, listing date) vs not-found, the additional wallet/contract classification per chain, the 'not legal advice' caveat, and the payment/auth requirement ($0.005 USDC on Base via x402). These are the behavioral details an agent needs and cannot infer from schema.

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?

Dense and front-loaded with the core question and scope before the return/payment details. Slightly long with parenthetical chain lists and 'and others', but 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?

For a no-annotation, no-output-schema tool, the description is nearly complete: it explains match/not-found return semantics, the classification add-on, and cost. Minor gap is no explicit signaling of failure/error behavior or rate limits, but coverage is strong.

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 baseline is 3. The description's mention of supported chains duplicates the chain enum documentation, but adds no format/syntax detail beyond what the schema already states for address and chain defaults.

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?

Opens with a specific question and verb+resource: screens a crypto address against the OFAC SDN digital currency list. Clearly distinct from sibling wallet/contract/balance tools, so an agent knows this is the sanctions check, not a profile lookup.

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 context for when to use it (sanctions screening of an address, per-chain wallet/contract classification) and which chains are supported. Does not explicitly compare against related tools like token_risk_check or prepayment_safety_check, so no exclusions/alternatives are stated.

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 at all, the description carries the full burden and does well: it discloses the cost ($0.003 per call), the payment rail (USDC on Base via x402), the input cap (16,000 characters), the output cap (1,024 tokens) and the return contents. It omits failure behavior (what happens if payment or the model call fails) and latency/retry expectations.

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?

Dense and front-loaded: capability first, then models, then limits, then price. The price is stated twice ('flat $0.003 a call' and '$0.003 USDC on Base via x402'), which is mild redundancy but the second instance does add the payment mechanism.

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 six-parameter, no-annotation, no-output-schema tool, the description covers models, input forms, size limits, output contents and payment. The main gap is the phantom messages-array input and the absence of any failure or payment-flow guidance.

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 parameters are already documented; the description adds the input/output size limits and the json=true flag. However it advertises an 'OpenAI-style messages array' alternative that does not exist in the schema (additionalProperties: false, only a single 'prompt' string), which is a real input-form inconsistency rather than added clarity.

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+resource ('LLM chat completion') and precisely what goes in and comes back ('send a prompt... get the reply text with token usage'). It does not reference the obvious sibling ai_chat_pro, so the agent must infer the difference from the flat price and small model list rather than being told.

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 pricing and the small model/size limits (a cheap, capped chat call), but there is no explicit 'use this instead of ai_chat_pro when...' or when-not guidance, despite a directly competing sibling in the tool list.

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 the flat $0.01 USDC cost on Base via x402 (a real auth/payment prerequisite), the 32,000-character input cap and 2,048-token output cap, and the default model. It omits what happens on payment failure or rate limiting, but the core behavioral profile is present.

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 verb and the I/O contract, then cost and limits. It is dense but nearly every clause carries information; the only slack is the parenthetical model enumeration, which the schema already lists.

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 stating the return shape (reply text plus token usage). Given six optional parameters, a payment requirement, and model selection, nothing an agent needs to invoke this 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%, so the baseline is 3, but the description adds meaning the schema does not: the 32,000-character input ceiling, the 2,048-token output ceiling, the input-shape choice between a prompt string and a messages array, and which model is the default. That is genuine value beyond the structured fields.

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 (chat completion), plus the distinguishing scope ('larger models') and the I/O contract ('prompt ... in, reply text and token usage out'). An agent can distinguish it from the sibling ai_chat purely on the 'larger models' framing 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?

Pricing and model size imply this is the heavier/paid tier relative to ai_chat, but the description never names ai_chat or ai_embeddings or states a condition for choosing between them. Usage is implied rather than prescribed.

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 load and does disclose the important behavioral traits: batching limits (up to 32 texts, 32,000 characters total) and a concrete price of $0.002 USDC on Base via x402, which signals that a paid x402 flow is involved before invocation. It does not explain payment failure behavior, rate limits, or what happens if the character budget is exceeded, keeping it below 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 dense sentences, front-loaded with model and dimensions, then capacity limits, then use cases, then price — no filler and nothing buried. The only minor opacity is the terse "POST texts array" wording, which does not cost enough to drop below 5.

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 one-parameter, no-output-schema tool, the description covers the essentials: model, vector size, batch capacity, intended applications, and cost/payment rail. The remaining gap is error and payment-flow behavior (what happens on insufficient USDC or on exceeding the character budget), which an agent would want before a paid call.

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 `text` parameter, so the baseline is 3, but the description adds real information the schema lacks: the 32-item batch cap and the 32,000-character aggregate limit. The phrase "POST texts array" is slightly opaque given the schema only declares a `text` property with additionalProperties=false, leaving a small ambiguity about the exact array key.

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 ("Text embeddings") plus the concrete model and vector dimensionality (bge-m3, 1,024 dims, multilingual), which is exactly what an agent needs to distinguish it from siblings like ai_chat or ai_translate. There is no ambiguity about what the tool returns or which modality it handles.

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?

"For semantic search, clustering and similarity" gives clear intended use cases that let an agent decide whether embeddings are the right primitive. It stops short of explicit exclusions (e.g., "not for generation — use ai_chat"), so it is a strong 4 rather than a 5.

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 supplied, the description carries the full burden and does well: it discloses the return format (1024x1024 JPEG as base64 inside JSON), the cost and payment rail ($0.01 USDC on Base via x402), and that seeds make results repeatable. What it omits is payment mechanics (automatic vs. prompted), latency, and failure behavior for a paid generation call.

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 action and model, followed by output shape, tunables, and price. No filler or redundant phrasing; each sentence adds a distinct fact.

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, and the description compensates by specifying dimensions, format, and encoding of the result, plus the monetary cost. For a three-parameter generation tool, an agent has everything needed to call it and interpret the response.

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 three parameters including ranges and the steps default of 4. The description only restates steps and adds the notion of repeatability for seed, which is marginal value beyond the schema's own 'Seed for a repeatable image' wording; the 1,000-character prompt cap is left to 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 verb and resource (generate an image from a text prompt) and names the underlying model, FLUX.1 [schnell]. This clearly separates it from the text-oriented siblings like ai_chat, ai_chat_pro, and ai_text_to_speech without needing the schema opened.

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 usage is strongly implied — supply a text prompt, get an image — but there is no explicit when-to-use/when-not guidance and no routing to alternatives (e.g., when to prefer ai_chat for descriptive text instead of rendering). The agent must infer the selection rule from the verb alone.

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 the 1,000-character cap, output encoding (base64 JSON), sample rate and channel count, the underlying model (MeloTTS), and a per-call price of $0.01 USDC on Base via x402. Payment mechanics and limits are exactly the behavior an agent needs before invoking. It stops short of stating what happens on over-length input or how payment failure surfaces.

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, each front-loading a distinct fact — purpose and output format, supported languages, then cost. No filler, no repetition of the tool name.

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 two-parameter tool with no output schema, the description supplies the return shape (base64 WAV in JSON), the size limit, and the pricing model, which covers what the schema cannot. The only gap is failure/error behavior for oversized text or unpaid requests.

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 both parameters are documented in-schema, so baseline 3 applies. The description's language list essentially restates the `lang` enum and the character limit restates the `text` pattern, adding no syntax, default, or fallback detail beyond structured data.

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 opens with a precise verb+resource (text to speech) and immediately specifies the output artifact: a WAV file (22 kHz mono) returned as base64 in JSON. That output shape distinguishes it from audio-consuming siblings like ai_transcribe, though the description never names that sibling or any other alternative 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?

Usage is implied by the name and the format details — an agent can infer it should call this when it needs spoken audio from text. There is no explicit when-to-use/when-not guidance and no routing statement pointing to ai_transcribe (the inverse direction) or ai_translate (for cross-language text).

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 supplied, the description carries the full disclosure burden and does well: it names the model, the accepted formats, the 15 MB ceiling, and the paid x402 model with a concrete price of $0.01 USDC on Base. What it omits is failure behaviour (oversized or unreachable URLs), whether the call is synchronous or long-running, and any retry/refund semantics for a paid endpoint, which are meaningful gaps for a metered 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?

Three tight sentences that front-load the capability, then constraints, then cost, with no throat-clearing. The one redundant fragment is 'Optional language hint,' which only restates what the schema already declares.

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 two-parameter tool with no output schema and no annotations, the description covers everything an agent needs: input formats and size cap, the optional hint and its default, the exact return fields (transcript, detected language, duration, word count, timed segments), and the cost. Return shape is described precisely enough that the absence of an output schema is not a handicap.

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 schema, including the two-letter pattern and the 'detected when omitted' fallback. The description adds file-format and size constraints that bound what the url parameter may point at, but framing the language hint as just 'Optional' repeats the schema rather than extending 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?

States a specific verb and resource ('Speech to text with Whisper large-v3 turbo') and immediately explains the calling contract: pass an audio URL, get back a transcript. It is unmistakably distinct from its nearest sibling, ai_text_to_speech, because the direction of conversion and the input type (audio URL) are both explicit.

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 conditions for use: the input must be a publicly reachable audio file in MP3, WAV, OGG or M4A at up to 15 MB, and the language hint is optional because detection happens automatically. It does not name alternatives or state when not to use it, but no sibling does the same job, so the context is sufficient.

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 full behavioral burden. It does disclose two valuable traits the annotations cannot: the 5,000-character ceiling and that each call costs $0.003 USDC on Base via x402 (a paid, non-refundable-per-call operation). However, it says nothing about failure modes, whether payment is charged on error, rate limits, or what happens for unsupported language pairs, which is thin coverage for a metered mutating-ish call with zero annotation support.

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 the operation first, then constraints, then cost — nothing redundant and every clause carries information an agent needs before calling.

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 three-parameter tool this covers operation, model, input limit, language handling, and payment. The only real gap is the return value: with no output schema, the description never says the translated string comes back under a particular field or what shape the response takes.

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 all three parameters are already documented ('Target language (fr, es, de, ja, zh...)', 'Source language; detected when omitted', 'Text to translate'). The description largely restates this, though 'ISO 639-1 code' adds a tighter specification of the accepted format than the loose `^[a-z]{2,3}$` pattern and example list in 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?

The description opens with a specific verb and resource: 'Translate text between 100 languages (m2m100)', naming the underlying model. This clearly separates it from chat/embedding/image siblings without needing to say so explicitly, but it never explicitly routes away from alternatives such as ai_chat for multilingual output.

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 context is implied by the hard limits ('up to 5,000 characters', auto-detected source) and the cost note, so an agent can infer it should not be used for long documents. There is no explicit when-to-use/when-not statement or named alternative for text that exceeds the character cap.

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 and adds important context: it discloses the $0.005 USDC x402 cost on Base and lists the detailed information returned. It does not explicitly state read-only behavior or rate limits, but 'Identify' and 'contract_info' strongly imply a read operation.

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 one dense but well-structured sentence that front-loads the core purpose and then lists the returned dimensions. Every item in the list earns its place by telling the agent what information is available, and the cost disclosure is appended without unnecessary preamble.

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 one simple parameter, no output schema, and no annotations, the description is complete enough for correct invocation. It explicitly lists the kinds of values returned, including EIP-7702 delegation, token standards, proxy implementation/admin, bytecode size, nonce, and ETH balance, so an agent knows what to expect.

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 the single 'address' parameter is already documented as 'Any address on Arbitrum One'. The description reinforces the Arbitrum One scope but adds no syntax, formatting, or usage detail beyond the schema, so the baseline 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, 'Identify', and clearly scopes it to an Arbitrum One address. It enumerates the exact distinctions and metadata it returns, including EOA vs contract, token standards, proxy details, bytecode size, nonce, and ETH balance, which makes it easy to distinguish from sibling tools such as wallet balances or token snapshots.

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 clearly establishes the usage context: inspect an Arbitrum One address for wallet/contract classification and contract metadata. It does not explicitly name when to prefer sibling tools like arbitrum_wallet_profile or arbitrum_token_snapshot, but the chain and purpose are sufficiently clear to guide selection.

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. It does add genuinely useful context beyond the schema: a concrete price ($0.005 USDC on Base via x402) and the shape of the returned facts, which implies a cheap read-only operation. But it omits whether payment is required before the call, what happens on unapproved pairs, or what the response format looks like.

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 core capability is front-loaded in one dense sentence, followed by a short pricing note. Both sentences earn their place, though the function list inside the first sentence is slightly packed and could be split for readability.

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 enumerating the four facts returned (allowance, unlimited flag, owner balance, spendable amount). For a three-address read tool this is nearly complete, missing only failure semantics for invalid or non-ERC-20 tokens.

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 all three addresses are already documented with their roles. The description adds only conceptual framing (owner granted the approval, spender may transfer) and no format or edge-case detail beyond the schema. 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 the exact resource (ERC-20 allowance), the chain (Arbitrum One), and what the result conveys: spender allowance, unlimited-approval flag, owner balance, and currently spendable amount. The chain qualifier cleanly separates it from the eth_/base_/optimism_/polygon_ siblings of the same name.

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 described output fields (checking approvals, spotting infinite approvals, residual balance), but there is no explicit when-to-use or when-not-to-use guidance. It never routes the agent to a sibling such as arbitrum_token_snapshot or token_risk_check for related questions.

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 substantial work: it discloses the payment model ($0.005 USDC on Base via x402), the price oracle used (Chainlink ETH/USD), and the sampling basis for the ranking (own samples every 10 minutes over 7 days). It does not describe response shape, failure modes, or how the x402 payment is actually settled, which are the remaining 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?

A single front-loaded sentence that leads with the core deliverable before the secondary analytics and the price. It is dense but the run-on 'plus how the current price ranks...' clause plus cost tail makes it harder to scan than a two-sentence split would be.

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?

Because there is no output schema and no annotations, the description must explain the return payload, and it does so field by field, including both the transfer cost estimates and the historical ranking. The one meaningful omission is that a paid x402 call is being invoked without explaining payment prerequisites or whether a prior x402_ping/prepayment check is expected.

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 schema provides nothing to clarify and the baseline is 4. However, the description's parameter-like content is entirely about returned fields rather than inputs, and it does not note that the tool is parameterless and always returns the same payload, leaving mild ambiguity about whether the 7-day comparison is configurable.

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 (current Arbitrum One gas conditions) and enumerates exactly what is returned: block number, base fee, gas price, priority fee in gwei, and ETH/USD cost estimates for native and ERC-20 transfers. Naming the chain explicitly separates it from base_gas_prices, eth_gas_prices, optimism_gas_prices and the other chain-scoped siblings.

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 'current' conditions and the cost note, but there is no explicit when-to-use or when-to-avoid guidance, and no comparison to the sibling chain gas tools. The optional 7-day historical percentile and 'usually cheapest UTC hour' features are folded into one clause rather than flagged as optional modes the agent might want.

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 useful work: it discloses that coverage is limited to the token's deepest WETH/USDC Uniswap v3 pools, that launch history is returned only when recorded, and that the call costs $0.02 USDC on Base via x402. It does not describe rate limits, error/empty behavior, or payment mechanics in more detail, preventing a top score.

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 dense but front-loaded and every clause contributes useful scope, output, or cost information. It could be easier to scan if split into shorter sentences, but it avoids filler and 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 complex, paid, multi-output tool with no output schema and no annotations, the description explains the returned data well: largest trades, volume/net flow, top wallets, and conditional launch history. It is nearly complete, with remaining gaps around error behavior and explicit alternative-tool 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 the parameters are already well documented. The description conceptually echoes the time window and USD-size filtering via 'last N minutes' and 'largest trades,' but it adds little parameter-level meaning beyond what the schema provides.

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 that this is a whale/large-trade tracker for an ERC-20 on Arbitrum One, including buys/sells in the last N minutes on Uniswap v3 WETH/USDC pools plus launch history. It distinguishes itself from other-chain large-trade siblings by naming Arbitrum One, but it does not explicitly contrast itself with nearby siblings like arbitrum_token_snapshot or token_risk_check.

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 scope: use it for recent large trades and wallet flow on an Arbitrum ERC-20, with optional launch-history context. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative tools, so the agent must infer routing from the description alone.

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 load and does disclose two important traits: a paid x402 call ($0.008 USDC on Base) and external fetching from IPFS/Arweave/HTTPS/data URIs, implying latency and possible upstream failures. It omits what happens when metadata resolution fails or is missing, 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?

A single dense sentence, front-loaded with the purpose then the return contents then the cost. Every clause carries information, though the run-on structure with a long appositive slightly hurts scannability.

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 effectively documents the return shape (collection name, owner, token URI, decoded metadata JSON, image URL), which is what an agent needs. Missing only edge-case behavior (missing/broken metadata, ERC-1155 owner semantics) to reach 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?

Schema coverage is 100% with both parameters fully documented (decimal tokenId pattern, contract address pattern). The description adds no parameter-level detail beyond 'on Arbitrum One', so 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?

States a specific resource (ERC-721/ERC-1155 token metadata) scoped to a specific chain (Arbitrum One), and lists the exact fields returned. An agent can distinguish it from arbitrum_contract_info or arbitrum_token_snapshot by the NFT-specific output described.

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 content ('NFT metadata'), but there is no explicit when-to-use or when-not-to-use guidance relative to siblings like arbitrum_contract_info or eth_nft_metadata (chain choice). The agent must infer selection from the chain scope alone.

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 and does so well: it discloses the paid cost model ($0.01 USDC on Base via x402), the data provenance (deepest WETH or USDC pool on Uniswap v3), the exact risk-score semantics (0-100 with reasons), and its neutrality stance. It omits failure modes (non-token or non-contract address handling) and data freshness/caching, 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?

One dense but well-ordered sentence that front-loads purpose before enumerating outputs, plus a short closing line on neutrality and pricing. Every clause maps to a real attribute an agent would care about; the output enumeration is long but earns its place given there is no output schema.

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, so the description must describe returns — it does, listing risk score, token metadata, ownership/renouncement, proxy detection, owner-only bytecode functions, and pricing/liquidity. Combined with the cost and data-source notes, an agent has what it needs to call and interpret the tool; only error/edge-case behavior is absent.

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's schema description already says 'Token contract address on Arbitrum One', so the description adds no new meaning about the address argument. 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+resource ('rug check and due-diligence snapshot of an ERC-20 token on Arbitrum One') and enumerates the exact data returned. The chain qualifier cleanly separates it from the base/eth/optimism/polygon/solana token_snapshot siblings, and 'ERC-20 token' separates it from arbitrum_contract_info.

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 opening phrase ('Rug check and due-diligence') gives an unambiguous use case, and 'Facts only, no buy or sell opinion' frames the intent. It stops short of naming alternatives or exclusions (e.g., when to prefer token_risk_check or arbitrum_contract_info instead), so it does not reach a 5.

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 disclose important behavioral context: the returned fields and the $0.005 USDC payment on Base via x402. It does not explicitly state read-only behavior, permission requirements, or failure modes, but the payment disclosure is materially useful.

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 purpose and return fields, followed by the payment cost. Every sentence earns its place with no redundancy.

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, but the description compensates by enumerating the summary fields an agent will receive. It also discloses the payment requirement, though it omits explicit prerequisites or error-handling notes for a paid read call.

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% for the single hash parameter, including its format pattern and that it must be an Arbitrum One transaction hash. The description does not add syntax or meaning beyond the schema, so the high-coverage 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?

The description states a specific verb and resource: a human-readable summary of an Arbitrum One transaction. It enumerates the exact fields returned, and the chain name distinguishes it from the many sibling *_transaction_summary tools.

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 chain-specific name and the required transaction hash, but the description never explicitly says when to use this instead of eth_transaction_summary, base_transaction_summary, or arbitrum_contract_info. The chain is clear, but alternatives are not named.

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 disclose real behavior: data is read live from Arbitrum One, results are formatted with symbol and decimals, and the call costs $0.005 USDC on Base via x402 — a payment prerequisite an agent must know before calling. It stops short of describing failure modes for invalid token addresses or whether the ETH entry is always included.

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 covering scope, chain, limit, formatting, and freshness, followed by the cost clause. The most decision-relevant information (what it returns, on which chain) is front-loaded 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?

For a two-parameter read tool with no output schema and no annotations, the description covers return content (ETH plus token balances with symbol/decimals), chain, limits, and the x402 payment requirement. Only the shape of the returned data and error conditions are left thin, which is a minor gap at this 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%, so both parameters are already documented in the schema. The description only restates the 20-token cap and the fact that ETH is always included alongside the listed tokens, adding marginal meaning beyond 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 gives a specific verb+resource: reads native ETH balance plus up to 20 listed ERC-20 token balances on Arbitrum One, live. It implicitly distinguishes itself from the base/eth/optimism/polygon siblings by naming the chain, but it never contrasts with arbitrum_wallet_profile or arbitrum_token_snapshot, which are the nearest overlapping siblings.

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?

'Tokens you list' implies the caller must supply contract addresses and that unlisted tokens are not returned, which is usable context. There is no explicit statement of when to prefer this over arbitrum_wallet_profile or arbitrum_token_snapshot, and no prerequisites beyond the cost note.

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 full behavioral burden. It usefully discloses the $0.005 USDC x402 cost and the full set of returned fields, but never states that the operation is read-only/non-destructive, what happens for invalid or non-existent addresses, or any rate or permission 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?

The purpose is front-loaded and the description is a single dense sentence with no filler. The long enumerated list of return fields is informative but borders on a laundry list; slightly tighter grouping of related items (e.g., token metadata vs proxy info) would improve scanability.

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 one-parameter lookup with no output schema and no annotations, the description does substantial work by naming all returned data and the cost. It is nearly complete, missing only error behavior and an explicit read-only assurance that annotations would normally provide.

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 the schema already documents it fully ('Any address on Base', with a 0x-pattern), giving 100% schema coverage. The description adds no syntax or format guidance beyond the schema, 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 verb and resource ('Identify what lives at a Base address') and enumerates the exact payload: EOA vs contract, token standards, name/symbol, proxy implementation and admin, bytecode size, nonce and ETH balance. This enumeration distinguishes it from siblings like base_wallet_balances, base_token_snapshot, and base_nft_metadata without needing to name them.

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 when to use it (classifying an address and retrieving contract metadata), but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as base_wallet_profile or base_transaction_summary. An agent can infer the use case but must decide on its own whether this or a sibling is appropriate.

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 disclose valuable context beyond the schema: the four result fields returned and the fact that the call costs $0.005 USDC on Base via x402. It does not explicitly state that it is a read-only/non-mutating call or describe failure modes, but the read-only nature is strongly implied by the query framing.

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 what is returned and followed by the payment cost. It is dense but every clause adds information; the only mild inefficiency is packing four return values into one long sentence.

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 appropriately enumerates the four result fields; it also discloses the x402 payment requirement, which an agent must know before calling. It stops short of explaining error behavior, token-decimal formatting, or how the unlimited-approval flag is determined, but for a three-address lookup tool it is largely 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?

Schema description coverage is 100%, and all three parameters are documented in the schema (token, owner, spender). The description does not add syntax, constraints, or edge-case guidance for those parameters, so it sits at the baseline.

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 specific verb/resource (ERC-20 allowance), the chain (Base), and the exact facts returned: allowance amount, unlimited-approval flag, owner balance, and currently spendable amount. This distinguishes it from the parallel eth_/arbitrum_/optimism_/polygon_erc20_allowance siblings and from base_wallet_balances.

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 name and the described outputs, but there is no explicit guidance on when to choose this vs. base_token_snapshot, base_wallet_balances, or another chain's allowance tool. The paid x402 note hints that it should only be called when the allowance question is genuinely needed, but no exclusion or alternative is named.

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 by disclosing the x402 payment cost, Chainlink ETH/USD rate source, 10-minute sampling over 7 days, and cheapest-hour insight. It does not explicitly state read-only behavior or response structure, but the informational nature is clear.

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 front-loaded with the key resource and is dense with relevant return-value details. It is somewhat long as a single sentence, but most included information helps an agent understand the paid data product.

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 zero-parameter data query with no output schema, the description comprehensively explains what will be returned: gas metrics, transfer-cost estimates in ETH and USD, historical ranking, cheapest UTC hour, and the x402 cost. Nothing essential for calling it correctly appears to be 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?

The tool has zero input parameters, so there is no parameter meaning to clarify. The baseline for a parameterless tool is therefore 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 precisely identifies a chain-specific gas-data resource: Base gas conditions with block number, base fee, gas price, priority fee, transfer-cost estimates, historical ranking, and cheapest UTC hour. The chain name distinguishes it from sibling gas-price tools such as eth_gas_prices and polygon_gas_prices.

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 explicit Base-chain scope, so an agent can infer this is the right tool for Base gas conditions rather than other chains. However, it does not explicitly state when to use this versus alternatives or any 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?

With no annotations at all, the description carries the full behavioral burden and does well: it discloses that the tool costs $0.02 USDC on Base via x402, that trades are drawn from the deepest WETH/USDC pools on Uniswap v3 or Aerodrome, and that launch history may be absent. It does not describe latency, failure modes, or pagination behavior, but it adds substantial context beyond a bare read.

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 opening clause is front-loaded with the core identity, and the single dense sentence avoids repetition. It is long and clause-heavy, but nearly every clause enumerates a distinct returned field or selection rule, so little is wasted.

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 annotations and no output schema, the description correctly takes on the job of describing the return shape: USD size, side, wallet, transaction, volume, net flow, top wallets, and optional launch history. Missing are error conditions (for example, when a token has no qualifying pools) and payment mechanics beyond the price.

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 all four parameters are already documented, with defaults and bounds. The description reinforces meaning by tying 'last N minutes' to the window, 'largest trades' to minUsd/limit, and the USD sizing of results, but it adds no format or edge-case detail beyond the schema. A 3 baseline 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 gives a specific verb+resource: a whale/large-trade tracker for an ERC-20 on Base, scoped to the token's deepest WETH/USDC pools over the last N minutes. It also enumerates the data returned, which clearly separates it from snapshot-style siblings such as base_token_snapshot and base_new_pools.

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 use case is clear, but there is no explicit guidance about when to choose this tool over base_token_snapshot, base_new_pools, or token_risk_check. The only conditional routing hint is implicit: launch data is returned only 'when we recorded 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?

With no annotations, the description carries the full behavioral burden and does disclose important context: the tool costs $0.008 USDC on Base via x402 and returns decoded metadata plus a browser-loadable image URL. It does not spell out error behavior, read-only semantics, or payment mechanics, so it falls short of a full behavioral profile.

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 compact and front-loaded: it states what the tool returns first, then adds the cost note. Both sentences carry useful information without 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 appropriately lists the important return values and metadata sources. It also discloses cost, but could be more complete by describing payment requirements or error cases for missing metadata.

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 contract and tokenId parameters are already fully documented in the schema. The description does not add parameter-level syntax or constraints beyond what the schema provides, 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?

The description names a specific resource (NFT metadata), chain (Base), and token standards (ERC-721/ERC-1155), and lists the returned fields. This clearly distinguishes it from sibling chain-specific NFT metadata tools such as eth_nft_metadata, arbitrum_nft_metadata, and polygon_nft_metadata.

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 clear usage context: this is for NFT metadata on Base, for ERC-721 or ERC-1155 tokens. It does not explicitly name sibling alternatives or state when not to use it, but the chain-specific framing is sufficient for an agent to route correctly.

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 burden and does well: it discloses the monetary cost ($0.005 USDC on Base via x402), which is critical behavioral context an agent cannot infer elsewhere. It stops short of describing the payment/settlement flow or the failure mode for unregistered names.

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: purpose and return values first, accepted input formats second, cost last. The parenthetical field list packs return-value detail without a separate sentence, and 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?

For a single-parameter lookup with no output schema and no annotations, the description supplies the return fields explicitly and discloses cost. The one gap is error behavior for unregistered or malformed names, which matters for an agent deciding whether to retry.

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 value by spelling out the three accepted input forms ("jesse", "jesse.base", "jesse.base.eth"), which is more concrete than the schema's regex pattern and tells the agent normalization is handled.

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 (resolve) and resource (Basename / name.base.eth) and specifies the return payload: Base address plus profile records. It is clearly distinguishable from the sibling eth_resolve_ens by naming the Base chain and .base.eth suffix convention.

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 it (whenever a .base.eth name must become an address) but never explicitly names the alternative tool or states exclusions, e.g. what to do for ENS names (eth_resolve_ens). Usage is inferable from the naming convention rather than stated.

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 so: it discloses the paid x402 flow and exact cost ($0.01 USDC on Base), the data provenance (deepest WETH or USDC pool on Uniswap v3 or Aerodrome), and that output is factual rather than advisory. These are exactly the operational facts an agent needs before committing to a paid call.

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-loaded with the core capability and output inventory, then closes with the decisive cost line. The middle clause is long and comma-dense but each item listed is return-relevant information, not 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?

No output schema and no annotations, yet the description enumerates the returned fields, states the price/liquidity source, and surfaces the payment cost and rail — everything needed to decide to call and to interpret the result. Only secondary gaps remain, such as behavior on a non-token address.

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 already documents the 0x-prefixed 40-hex contract address format. The description adds only the ERC-20-on-Base framing, which is implicit in the tool name and schema, so it neither fills a gap nor adds syntax guidance.

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: a rug-check/due-diligence snapshot of an ERC-20 token on Base, and enumerates exactly what it returns (risk score, supply, owner, proxy detection, owner-only functions, price/liquidity/FDV). The Base prefix separates it from the arbitrum/eth/optimism/polygon/solana snapshot siblings, but it never distinguishes itself from token_risk_check, which sounds like an overlapping capability.

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 'rug check and due-diligence' and the 'facts only, no buy or sell opinion' scope framing, but there is no explicit when-to-use or when-to-avoid, and no pointer to token_risk_check or base_contract_info as the alternative for narrower questions.

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 burden and does disclose a genuinely important behavioral trait: the $0.005 USDC x402 cost. It also tells the agent the shape of the return. It does not say what happens on an unknown hash or whether the call fails vs returns empty, 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 purpose then cost. The field enumeration is dense but each item is informative; nothing is filler, though the list could be trimmed slightly without losing selection 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?

There is no output schema, so the description correctly compensates by enumerating the returned data (status, block/time, parties, value, gas, method, decoded ERC-20 transfers). Cost and chain are covered; error/not-found behavior is the only missing piece an agent would want.

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 and schema coverage is 100%, with the schema already documenting the hash including its 0x…64-hex pattern. The description adds the implicit "on Base" scoping but no further format or sourcing detail, so 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+resource ("Human-readable summary of a Base transaction") and enumerates the fields returned, so an agent knows exactly what it gets. The chain qualifier plus the field list cleanly separates it from eth_/arbitrum_/optimism_/polygon_transaction_summary siblings.

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 chain prefix and the required hash, but there is no explicit "use this when... / use X instead" guidance, no note that the hash must belong to Base, and no mention of the sibling per-chain summaries. The agent must infer routing from the tool name alone.

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 load and does well: it discloses that values are read live from Base, are formatted with each token's symbol and decimals, and — critically — that invoking it costs $0.005 USDC via x402. That payment disclosure is behavioral context an agent cannot get from the schema. It still omits error/edge behavior, e.g. invalid or non-ERC-20 token addresses, empty results, or whether pricing is per call.

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 with zero filler: what is returned, how it is formatted, where it is read from, and what it costs. Nothing needs trimming and the core payload leads the sentence.

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 2-parameter read tool with no output schema, the description covers return shape (symbol and decimals formatting), data freshness (live), and cost. Remaining gap is failure/edge behavior for invalid token addresses or a mix of token types, which an agent would benefit from knowing.

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 are documented in-schema with regex patterns, so the baseline is 3. The description restates the 20-token cap and the output formatting, which adds mild value but no syntax or format detail 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 verb and resource: reads native ETH balance plus up to 20 listed ERC-20 token balances on Base. The chain scoping ('Base wallet') implicitly separates it from eth_wallet_balances, arbitrum_wallet_balances and the other chain siblings, though it never names a sibling or explains the difference from base_wallet_profile.

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 applies when it needs balance data on Base and has an address plus an optional token list. There is no explicit when-to-use/when-not-to-use guidance and no pointer to alternatives such as base_wallet_profile or base_token_snapshot.

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 weekend exclusion, observed-weekday shifting of weekend holidays, half-open interval semantics, that skipped holidays are returned, and — importantly — that invocation costs $0.005 USDC on Base via x402. It stops short of describing the exact response shape (e.g. field names for the count).

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 the core computation front-loaded and the payment note correctly placed last. Every clause carries information; the only mild redundancy is restating the interval boundary already present in the schema.

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 three-parameter, no-output-schema, no-annotation tool, this covers the essentials: what is counted, what is excluded, how boundaries behave, what extra data comes back, and the payment requirement. Only the precise return payload structure is left unspecified.

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 three parameters including the half-open 'to' semantics. The description's restatement of counting 'up to but not including the end date' reinforces that boundary but adds little beyond the schema's 'Day after the last day counted'.

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: counting business days between two dates for a Canadian province/territory, with the exclusion rules spelled out. An agent can tell this apart from canada_sales_tax, though it never explicitly contrasts itself with canada_statutory_holidays, which is the closest sibling given this tool also mentions returning skipped holidays.

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 computation described (use it when you need a working-day count for a province), but there is no explicit when-to-use/when-not, and no guidance on choosing between this and canada_statutory_holidays when the user wants holiday data rather than a count.

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 rounding to the cent, date-driven rate lookup with today as default, and — importantly for an agent — the x402 payment cost of $0.005 USDC on Base. It does not cover failure modes (invalid province code, out-of-range date), which keeps it from 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 sentences, each earning its place: what it returns, how dates drive rates, what it costs. The output shape is front-loaded before the caveats.

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 must describe the return — and it does, enumerating the tax components, per-rate and per-amount rounding, and the total. Amounts are stated in CAD. An agent has everything needed to call it and interpret the result.

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 baseline is 3. The description confirms province/amount/date usage and adds the 'pre-tax' and 'default today' framing, but adds no format or syntax details beyond what the enum and patterns already specify.

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: computes a Canadian sales tax breakdown (GST/HST/PST/RST/QST) for an amount in a province or territory. Nothing among the siblings (canada_business_days, canada_statutory_holidays, fx_ecb_convert) overlaps, and the description makes the distinction obvious without opening schemas.

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?

Clear context for when to reach for it: any CAD pre-tax amount needing province-level sales tax, with the date parameter used for historical rate changes (Nova Scotia 2025 HST cut). It stops short of explicit when-not guidance or naming an adjacent tool to use instead, but for a narrowly scoped calculator nothing is genuinely ambiguous.

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 burden and does add real context: it discloses that names are localized per province, that weekend holidays surface the observed weekday, and that invocation costs $0.01 USDC on Base via x402 — an important payment/auth trait an agent cannot infer from the schema. It stops short of explaining the observation/substitution rule precisely or what happens for invalid province/year combinations.

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 resource and scope, followed by the cost disclosure. No redundant restatement of the tool name and nothing 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?

For a two-parameter lookup with no output schema, the description covers what comes back (holiday names, actual date, observed weekday) and the payment model, which is enough for correct invocation. The only remaining gap is the precise weekend-substitution rule, which affects interpreting the returned weekday.

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% (year pattern 2000-2100, province enum with a clear description), so the schema already documents both parameters fully. The description merely restates 'province or territory' and 'given year' without adding format or edge-case semantics, which is the baseline-3 case.

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 the exact resource (statutory/general holidays) plus scope (one Canadian province or territory, one year) and the returned content (local holiday names, dates, observed weekday). It is immediately distinguishable from canada_business_days and canada_sales_tax by subject matter, though it never names those siblings or states the contrast 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?

Usage is implied by the resource itself — call it when you need provincial holiday dates for a given year — and the x402 cost line gives a practical precondition (payment required). However there is no explicit when-to-use/when-not guidance and no pointer to the related canada_business_days or canada_sales_tax tools.

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 the result cap (newest 50), the exact fields returned, that total counts come back alongside, and — critically — that the call costs $0.005 USDC on Base via x402, a payment prerequisite an agent must know before invoking. It does not cover rate limits, error behavior for unsupported ATS, or whether the counts imply pagination beyond 50.

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: scope and supported sources first, then inputs, then return shape and price last. Every sentence adds distinct information with no filler, and the cost disclosure is placed where an agent will still read it.

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 and the 50-result cap so an agent need not probe for the response shape, and it discloses the payment requirement. It is complete for a lookup tool, with only failure modes (unsupported ATS, zero results) left 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?

Schema description coverage is 100%, so the schema already documents every parameter, including the comma-separated title pattern and the remote enum. The description only restates the parameter set generically ('optional title, location and remote filters') without adding syntax or edge-case meaning, 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?

The description opens with a precise verb+resource: open jobs at a specific company pulled from its own public ATS job board, and enumerates the ten supported ATS platforms (Greenhouse, Lever, Ashby, Workable, SmartRecruiters, Recruitee, BambooHR, Personio, Teamtailor, Workday). The required 'company' scoping effectively separates it from the generic jobs_search/jobs_new siblings, though it never names an alternative 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?

It states the acceptable input forms (company name, website, or job-board URL) and that title/location/remote are optional filters, which implies the use case of per-company job lookup. However, it gives no when-not guidance, no mention of what happens when a company has no supported ATS, and no comparison to the sibling job tools.

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 burden and does well: it discloses the price source (DefiLlama aggregation) and the payment requirement (costs $0.002 USDC on Base via x402), which is important pre-call context. It omits rate limits, failure behavior for unknown symbols, and staleness/latency of the prices.

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 covering capability, input forms, source, and cost with no filler. It is dense with parenthetical examples, which costs a bit of readability but nothing is wasted.

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 one-parameter read tool with no output schema and no annotations, the description covers inputs, limits, data provenance, and cost — the essentials an agent needs to invoke it. Remaining gaps (error handling, response shape, price freshness) are minor.

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 already documents the comma-separated format, but the description adds concrete examples for each accepted identifier form (symbols, coingecko:<id>, base:0x..., solana:<mint>) plus the 20-token cap that does not appear in the schema at all.

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 (current USD price and 24-hour change for crypto tokens) with an explicit scope limit (up to 20 tokens in one call) and names the underlying source (DefiLlama aggregated prices), so an agent can tell it apart from the per-chain token_snapshot siblings.

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 context for when this is the right call: batch pricing of up to 20 tokens in a single request. It does not explicitly name alternatives (e.g. eth_token_snapshot) or state exclusions, so it falls short of a 5.

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 present, the description carries the full burden and does substantial work: it names the billable cost ($0.01 USDC on Base via x402, which affects whether an agent should call it), discloses the data provenance and cutoff (own launch records since 2026-10-23), and states the filtering policy (exchanges, bridges and busy services flagged, never linked). This goes well beyond a bare 'looks up a deployer' statement.

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 opening question frames the intent quickly, followed by a dense but information-bearing sentence and a short cost/disclaimer closer. Almost every clause contributes (chains, filtering policy, data cutoff, price), though the run-on middle sentence packs several distinct facts into one breath and the 'Not advice' disclaimer is marginal.

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 multi-chain enrichment tool with no annotations and no output schema, the description supplies the return shape, data freshness, filtering rules, and payment requirement. Remaining gaps are minor: error behavior when no funder is found, and any pagination or size limits on the returned token/deployer lists.

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 and the chain enum are already documented, including the base58/default-chain behavior. The description corroborates by listing the six supported chains and noting that a token address triggers a deployer lookup, but adds little that the schema does not already say. 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 concretely states what the tool returns: the wallet that first funded the deployer, the other deployers that wallet funded, their tokens, and how many lost liquidity within a week. That is a specific resource and output, not a restatement of the name. It never mentions the sibling deployer_record, so an agent cannot tell from the text alone which of the two to call.

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 investigative framing ('serial ruggers launch each token from a fresh wallet funded from one source') and by stating that either a deployer wallet or a token address may be passed. However, no when-not conditions or named alternatives (deployer_record, token_risk_check, token_verdict) are given, so the routing decision 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 data provenance (own history of new pools), a hard coverage cutoff (since 2026-10-23), the exact output dimensions, and — critically — that calls cost $0.005 USDC on Base via x402, which an agent must know before invoking. It stops short of describing failure modes (unknown/never-seen deployer, empty history) or latency/rate-limit 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?

Front-loaded with the question the tool answers, then the substantive scope and output, then the call-to-action and the cost caveat. The middle sentence is long and clause-dense but every clause (chains, cutoff, risk-at-launch, 24h/7d liquidity, verdict taxonomy) 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?

There is no output schema, and the description compensates by enumerating the returned fields and the five verdict values, plus provenance and payment requirements — enough for an agent to decide and call correctly. The remaining gap is behavior for wallets with no launch history or addresses outside the tracked pool set.

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%, including the chain enum and the defaulting rule (solana for base58, otherwise base), so the schema already does the heavy lifting. The description echoes that address may be a deployer wallet or a token address and lists the six chains, but adds no new semantics such as what happens if a supplied chain conflicts with the address format.

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: a creator's launch record across named chains drawn from the provider's own new-pool history, returning launch risk score, 24h/7d liquidity survival, and a verdict. That is clearly distinct from siblings like token_risk_check, token_verdict, or *_wallet_profile, which operate on a token or wallet at a single point rather than a deployer's full launch history.

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?

"Pass the deployer wallet or a token address" gives invocation guidance (and the address schema repeats it), and the description implies the decision context — vetting a creator before trusting a token. But it never contrasts itself with token_verdict, token_risk_check, or the chain-specific wallet_profile tools, and gives no exclusions or preconditions beyond the date cutoff.

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 and does disclose several non-obvious traits: the 20 MB size ceiling, the exact output shape (Markdown plus character, word and token counts), and a paid x402 price of $0.005 USDC on Base. It does not cover failure modes (unsupported format, non-public URL, >20 MB behavior), which keeps 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 sentences, zero filler, and the core purpose is front-loaded ahead of constraints and pricing. Every clause (formats, size cap, return fields, cost) carries information an agent needs before calling.

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?

Since there is no output schema, the description usefully spells out what comes back (Markdown plus counts), which is exactly the gap it needs to fill. The one-parameter schema is fully documented, so the only real omission is error/edge-case behavior for unsupported or oversized documents.

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?

Placeholder — replaced below by the correct value.

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 ('Convert a document at a URL to Markdown') and immediately scopes it to an LLM use case, then enumerates exactly which document types qualify. An agent can distinguish this from the nearby web_extract or ai_* siblings because the description is document-format-scoped rather than page- or prompt-scoped.

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 supported-format list (PDF, DOCX, XLSX/XLS, ODT/ODS, CSV, XML) and the 20 MB cap implicitly tell the agent when the tool applies, and the format list also implicitly excludes HTML pages. However, no alternative is ever named, so the agent gets no explicit routing instruction against siblings like web_extract.

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 disclose the critical non-obvious behavior: the call costs $0.005 USDC on Base via x402, which affects whether an agent should invoke it. It also clarifies that each metric comes with current year, previous year and change, so the caller knows the shape of the mutating-free lookup. It omits error/failure behavior for unrecognized countries and any 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?

Front-loaded with the core resource and metric list, then a short second sentence covering the payment requirement. The long metric enumeration is information-dense rather than padding, though it could be grouped (e.g. 'GDP variants, inflation, unemployment, demographics, external sector') for faster scanning.

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, so the description must convey return content, and it does so thoroughly (metric list, year/previous/change structure, region/income/capital). Payment cost is also covered. Missing only edge details an agent might want: what happens for an unknown country, and how fresh the underlying data is beyond 'latest year'.

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 already documents ISO-code-or-name acceptance with a pattern constraint, so the description adds no parameter-level meaning. Baseline 3 applies since the schema does the work.

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 (World Bank headline economics for a country) and enumerates the metrics returned, plus supplementary fields (region, income level, capital). An agent can tell immediately this is a macro-economic country lookup, distinct from every sibling (crypto, company, FX, jobs tools).

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 data domain; there is no explicit when-to-use, when-not-to-use, or pointer to alternatives. In practice there is no close sibling for macro data, so the practical risk is low, but the description itself provides no routing guidance.

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 a critical non-obvious behavior — the tool is paid, costing $0.005 USDC on Base via x402 — which tells the agent a payment/auth flow is required before calling. It also implies the response contents, though it says nothing about failure modes, rate limits, or handling of non-existent addresses.

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 front-loaded sentences: the capability enumeration first, the payment condition second. The long list of returned attributes is dense but every item is load-bearing given there is no output schema, and no sentence 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?

For a one-parameter classification tool with no output schema and no annotations, the description supplies both the return-value inventory and the payment model — the two things an agent would otherwise have to discover by trial. Nothing essential 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?

Only one parameter, and schema description coverage is 100% ('Any address on Ethereum', with a 0x-prefixed 40-hex pattern). The description contributes no additional syntax or constraints beyond scope confirmation, 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?

Specific verb ('Identify what lives at') plus an explicit enumeration of what is returned: EOA vs contract, EIP-7702 delegation, token standard, name/symbol, proxy implementation/admin, bytecode size, nonce, balance. The chain-prefixed name plus 'Ethereum address' cleanly separates it from base_contract_info/arbitrum_contract_info and other siblings.

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 when it applies (classifying an address or inspecting a contract), but there is no explicit when/when-not, no mention of alternatives such as eth_wallet_profile, eth_token_snapshot, or eth_wallet_balances, and no stated prerequisites. Usage is inferable rather than guided.

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 burden, and it does add useful context: it lists the returned data points and discloses that the call costs $0.005 USDC on Base via x402. It does not describe side effects, error behavior, or rate limits beyond the per-call price, but the read-only nature is strongly implied by the query framing.

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 compact sentences with no wasted wording. The core purpose and return values are front-loaded, and the cost/payment detail is kept brief and separate.

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 key return values and notes the payment mechanism. For a simple three-parameter read query, this is largely complete, though it could be stronger with explicit read-only confirmation or error/ failure conditions.

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 the schema already defines owner, token, and spender with address patterns. The description names the concepts but adds no format, constraints, or interpretation beyond what the schema provides, so the baseline 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 states a precise verb+resource combination: 'ERC-20 allowance on Ethereum.' It also enumerates exactly what the tool returns (allowance, unlimited-approval flag, owner balance, spendable amount), and the 'on Ethereum' qualifier distinguishes it from sibling chain-specific allowance tools such as arbitrum_erc20_allowance and base_erc20_allowance.

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 scope 'ERC-20 allowance on Ethereum,' and the Ethereum qualifier helps route between sibling chain tools. However, there is no explicit guidance on when to use this versus related tools like eth_token_snapshot or eth_wallet_balances, and no stated exclusions or prerequisites beyond the payment note.

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 discharges most of it: it discloses the pricing model ('Costs $0.005 USDC on Base via x402'), the oracle behind the USD conversion (Chainlink ETH/USD), and the sampling methodology for the percentile ('our own samples every 10 minutes over the last 7 days'). It stops short of stating whether payment is required per call, what happens on failed payment, or whether the free-tier/lite sibling should be preferred, leaving a small gap for an agent that needs to reason about cost.

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?

It is a single dense sentence, but it is front-loaded with the primary payload (current gas conditions) and each subsequent clause — units, USD conversion source, percentile methodology, cheapest hour, price — adds distinct information. The one structural weakness is that the run-on construction makes the x402 cost clause easy to skim past, when it is arguably the most decision-relevant detail.

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 is the only specification an agent has, and it fully describes the return payload: named fields, units (gwei, ETH, USD), what the cost estimates cover (native and ERC-20 transfers), the comparative statistic and its sample window, and the derived cheapest-hour signal. Nothing material about calling this zero-argument tool is left undocumented.

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 baseline of 4 applies; there is nothing for the description to disambiguate. The description correctly spends no words on inputs and instead details the output surface, which is the only meaningful semantic content for a parameterless tool.

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 opens with a specific verb-and-resource framing ('Current Ethereum gas conditions') and enumerates the exact returned fields (block number, base fee, gas price, priority fee in gwei), which lets an agent understand the operation without opening a schema. The chain qualifier 'Ethereum' implicitly separates it from the arbitrum_/base_/optimism_gas_prices siblings, though it never names the alternative 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?

Usage is only implied: an agent can infer that this is the tool to call when it needs current mainnet gas estimates or a 7-day price percentile. There is no explicit when-to-use/when-not guidance, no mention of the sibling gas-prices tools for other chains, and no note on data freshness or staleness windows that would tell an agent when a cached read is adequate.

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 the data source (deepest WETH/USDC Uniswap v3 pools), the cost and payment rail ($0.02 USDC on Base via x402), and the important coverage caveat that launch history is only present 'when we recorded it'. It stops short of describing rate limits, error/failure modes, or empty-result 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?

Content is front-loaded with the resource and then the returned data, and every clause (pool selection, caveat, pricing) carries information. It is a long run-on sentence with heavy semicolon/comma stacking, which costs a little readability, but there is 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?

For a tool with no output schema and no annotations, the description adequately explains what comes back (trade list, aggregates, top wallets, conditional launch history) and its cost. Minor gaps remain: no statement of what happens when the token lacks qualifying pools or no trades fall in the window, and nothing on response size/latency.

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 params with ranges and defaults; baseline 3 applies. The description adds only light framing ('last N minutes', 'largest trades', implicitly minUsd as a size floor) and no new syntax or interpretation 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?

The description names a specific verb+resource ('Whale and large-trade tracker for an ERC-20 on Ethereum') and enumerates the concrete data returned (USD size, side, wallet, tx, volume, net flow, top wallets, launch history). It implicitly distinguishes itself from the siblings arbitrum_large_trades / base_large_trades / polygon_large_trades by the chain qualifier 'on Ethereum'.

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 for large-trade/whale flow on a specific ERC-20, and the minUsd/minutes params reinforce that. But there is no explicit when-to-use or when-not-to-use guidance versus nearby siblings such as eth_token_snapshot, token_risk_check or deployer_record, nor any note on prerequisites (e.g. that the token must have deep WETH/USDC Uniswap v3 pools for meaningful 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 full burden and does well: it discloses that metadata is fetched from IPFS, Arweave, HTTPS, or inline data URIs, that an image URL is produced, and that the call costs $0.008 USDC on Base via x402. It does not cover failure behavior, token-standard-specific limitations, or payment mechanics beyond price, which keeps it from 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?

It is a single dense sentence, front-loaded with the core resource and return contents, followed by the payment detail. Every clause adds useful information, though the sentence is long enough that it could be split for easier scanning.

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 adequately covers return values and the payment requirement, which are the critical pieces an agent needs. It omits error handling and edge cases such as missing metadata or ERC-1155 owner semantics, leaving a small gap.

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 `contract` and `tokenId` fully. The description mentions ERC-721 vs ERC-1155 behavior for owner retrieval but adds little parameter-level semantics beyond what the schema provides, making 3 the correct baseline.

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 (ERC-721/ERC-1155 token metadata) and enumerates exactly what is returned: collection name, owner, token URI, decoded metadata JSON, and image URL. The chain qualifier 'on Ethereum' distinguishes it from the many sibling `*_nft_metadata` tools for other networks.

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 context is clear: use this for NFT metadata on Ethereum, as opposed to contract info or token snapshots. However, it does not explicitly name alternatives or say when *not* to use it, leaving sibling selection mostly to the agent's 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 real weight and does so: it discloses the resolver used (universal resolver) and the payment requirement ($0.005 USDC on Base via x402), which is critical for an agent to avoid unexpected failure. It omits behavior on unresolvable names and any partial-result semantics.

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 plus two short supporting sentences; the resolution direction and the returned record types lead, and the cost/auth note trails. No filler and nothing 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?

Without an output schema or annotations, the description still tells the agent what comes back (address, avatar, description, url, Twitter, GitHub) and what it costs. Missing are failure/empty-result behavior and whether supplying both parameters is an error — meaningful for a paid, zero-required-param 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?

Schema coverage is 100%, so both parameters are documented at the structured level. The description adds value by framing them as alternatives — name for forward resolution, address for reverse lookup — and by enumerating the record types returned, which the schema does not convey.

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 (resolve) and resource (ENS name), covering both directions: forward resolution to address plus profile records, and reverse lookup from address to primary name. The `eth_` prefix and ENS specificity clearly separate it from `base_resolve_basename` among the siblings.

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?

Explicitly states the two usage modes with example inputs ("vitalik.eth" vs "pass an address instead"), giving clear context for when each parameter applies. It stops short of naming the basename sibling as the alternative for Base names, leaving that distinction to the naming convention.

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 useful work: it discloses the exact paid-call cost ($0.01 USDC on Base via x402) and states 'Facts only, no buy or sell opinion.' It still does not explicitly state read-only/non-destructive behavior, rate limits, or error conditions, but it adds substantial context beyond the schema.

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 front-loaded with the core purpose and contains no filler; every clause about outputs, no-opinion stance, and cost is relevant. However, the long output-field enumeration makes it dense and slightly less scannable than it could be.

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 that there is no output schema and no annotations, the description does a thorough job enumerating the returned risk score, token metadata, ownership details, proxy detection, bytecode findings, and market data. It also discloses payment cost and source pools, leaving little essential context missing for a one-parameter snapshot 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?

There is only one parameter, and the input schema already fully documents it with a pattern and description ('Token contract address on Ethereum'). The description restates the Ethereum/ERC-20 context but adds no further syntax or semantic detail beyond the schema, so the baseline 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 clearly states a specific resource and scope: a due-diligence snapshot of an ERC-20 token on Ethereum, with a detailed enumeration of returned fields. It does not explicitly distinguish itself from nearby siblings like token_risk_check or eth_contract_info, so it falls short of full sibling differentiation.

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 phrases 'Rug check and due-diligence snapshot' imply the intended use case, but the description gives no explicit when-to-use guidance, exclusions, or alternatives among the many sibling tools. An agent can infer the context, but routing decisions remain underspecified.

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 exist, so the description carries the full behavioral burden. It does the two highest-value things: it discloses a real cost ('$0.005 USDC on Base via x402') — critical for an agent deciding whether to call — and it enumerates the returned content, which implicitly establishes this is a read-only lookup. Gaps remain on failure behavior (nonexistent hash, unconfirmed/pending tx) and latency.

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 padding. The payload enumeration is front-loaded and the payment caveat is placed last where it reads as a footnote, which is the right ordering.

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?

Since no output schema exists, the field enumeration in the description is doing necessary work and covers the return value well. The only real omissions are error/not-found semantics and whether transfers covers only ERC-20 (it says so) or also native/NFT movement — minor against an otherwise complete definition.

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?

Single parameter with 100% schema description coverage, including a pattern constraint and a description ('Transaction hash on Ethereum'), so the schema does all the work. Baseline 4 for a one-param tool; the description adds nothing beyond it, but nothing is missing either.

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+resource ('Human-readable summary of a Ethereum transaction') followed by an enumeration of exactly what the summary contains (status, block/time, sender/recipient, value, gas, method selector, decoded ERC-20 transfers). The 'Ethereum' qualifier plus the eth_ prefix distinguish it from the arbitrum_/base_/optimism_/polygon_transaction_summary siblings.

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 required hash parameter and the 'transaction summary' framing make the lookup use case obvious, but the description never says when to prefer this over eth_wallet_profile or eth_token_snapshot, nor does it explicitly say 'mainnet only — use base_transaction_summary for Base'.

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 meaningful work: it discloses that reads are live from chain, that the call is a paid x402 endpoint costing $0.005 USDC on Base, and that output is decorated with symbol and decimals. It omits failure behavior (unverified tokens, payment rejection) and rate limits, so it falls 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?

A single dense sentence that front-loads the return value and ends with the cost caveat, with no filler. Slightly packed — the payment detail and formatting detail compete for one clause — but nothing is wasted.

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 2-parameter tool with no output schema, the description conveys what comes back (native balance plus per-token balances with symbol/decimals) and the commercial precondition (x402 payment). What's missing is error handling for tokens lacking metadata and any hint of response shape beyond formatting.

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 both parameters already document address format and the comma-separated, max-20 token contract list. The description's 'up to 20 ERC-20 tokens you list' restates the schema rather than adding new syntax, ordering, or edge-case guidance, so 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+resource: returns native ETH balance plus up to 20 ERC-20 token balances for a wallet, read live from Ethereum, with symbol/decimals formatting. The chain qualifier 'on Ethereum' clearly distinguishes it from the arbitrum_/base_/polygon_/optimism_wallet_balances siblings.

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 implies usage (check a wallet's ETH and listed ERC-20 holdings) and notes the x402 cost, but never states when to prefer eth_wallet_profile or eth_token_snapshot, nor any prerequisite such as holding USDC on Base to pay. The alternative routing 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 burden and does reasonably well: it discloses the paid nature ($0.005 USDC on Base via x402), the data source, and what is returned (rate used, result, rate date). It stops short of stating rounding behavior or what happens on non-publishing days.

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: the operation and its scope come first, the payment cost last. No filler and nothing redundant with the schema.

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, but the description enumerates the return payload, which covers the main gap. Minor omissions remain around rate availability on non-business days and whether the conversion is EUR-crossed, but nothing essential for correct invocation 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%, so every parameter is already documented in the schema. The description only echoes the optional-date behavior and says nothing extra about cross-rate mechanics or amount precision, 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 and resource ('Convert an amount between two currencies') plus the exact rate source (ECB daily reference rate), so the agent knows precisely what it gets. It does not mention the sibling fx_ecb_rates, so the distinction between converting and merely listing rates must be inferred.

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?

'latest or for a past date' implies when the optional date parameter should be supplied, which is useful context. However, there is no explicit guidance on when to pick this over fx_ecb_rates, nor any note about weekends/holidays when ECB publishes no rate.

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 update cadence (once per working day), that the response states the effective day, the ~30 currency universe, and a paid x402 cost of $0.005 USDC on Base. Missing only error/failure behavior and any rate-limit or caching notes.

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, front-loaded with resource and scope, then cadence, then payment cost. 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?

For a zero-required-param read tool with no output schema, the description covers cadence, effective-date reporting, currency coverage, and payment cost — everything needed to invoke it. A brief note on returned structure or the convert alternative would make it 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?

Schema description coverage is 100%, so all three parameters are already documented, giving a baseline of 3. The description reinforces base-currency and date semantics but adds no format or interaction detail 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 (European Central Bank daily reference rates) and scope (about 30 major currencies, any base, latest or historical). An agent can tell this returns rate data rather than computing a conversion, but it never names fx_ecb_convert, so the sibling boundary must be inferred.

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?

"Latest or for a past date" gives implicit selection guidance, but there is no explicit when-to-use statement and no routing to fx_ecb_convert for actual currency conversion. The usage context is inferable rather than stated.

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 and does so thoroughly: it discloses data provenance and scale (about 20,000 company job boards), refresh cadence (crawled twice a day), a critical selection-bias caveat (only postings that publish pay), the return shape (p10/p25/median/p75/p90, typical range, remote vs on-site medians, top-paying companies, posting count), and the paid access model ($0.01 USDC on Base via x402). An agent knows both the economics and the reliability limits of the call before invoking it.

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 that front-load the core purpose and then layer provenance, output fields and pricing in a logical order; almost nothing is wasted. The second sentence is a long run-on list but remains scannable.

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 four-parameter read tool with no output schema and no annotations, the description covers purpose, inputs, return fields, data source, freshness and cost, which is enough to call it correctly. It omits edge behavior — what is returned when a title matches no paid postings, or how title matching (exact vs. fuzzy) works — leaving a modest gap.

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 every parameter is already documented in the input schema, including comma-separated title alternatives and the currency default. The description only summarizes 'Optional location, remote and currency' without adding format or matching semantics beyond the schema, which is the expected baseline 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 description opens with a specific verb-and-resource statement ('Salary for a job title: how much a role pays') and pins down the data source ('open postings that publish pay'), so an agent immediately knows this is an aggregated salary lookup rather than a listing search. It does not explicitly distinguish itself from the similarly named siblings jobs_search, jobs_new or company_jobs, 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?

Usage is only implied: the phrase 'Salary for a job title' tells an agent this is the pay-statistics tool, and 'from open postings that publish pay' hints at the coverage caveat. But there is no explicit when-to-use versus jobs_search or company_jobs, no statement of when not to use it, and no routing guidance for alternative tools.

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 identification behavior, EIP-7702 delegation handling, proxy/admin detection, bytecode size, nonce, ETH balance, and the x402 payment cost. It does not explicitly state read-only/no side effects or rate limits, but the 'Identify' framing and cost disclosure make the read operation clear.

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 front-loaded with the core purpose and then enumerates useful return details. It is dense but mostly earns its length; the long capability list is relevant, though slightly list-heavy.

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 one-parameter read tool with no output schema, the description thoroughly enumerates the important return values: wallet vs contract, token standards, name/symbol, proxy implementation/admin, smart-wallet proxies, bytecode size, nonce, ETH balance, and cost. That is enough for an agent to know what to expect from the call.

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 input schema has 100% description coverage for the single address parameter, so the schema already explains the expected input. The description adds only the OP Mainnet context and does not provide extra syntax or format details 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?

The description uses a specific verb, 'Identify', and clearly names the resource: what lives at an OP Mainnet address. It explicitly distinguishes wallet/EOA, EIP-7702 delegation, contracts, token standards, proxy details, and metadata, so an agent can understand the tool's scope 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?

The description implies usage by listing what the tool returns and naming the chain, but it does not explicitly say when to use this instead of siblings like optimism_wallet_profile, optimism_wallet_balances, or optimism_token_snapshot. The $0.005 cost is useful context but not a usage rule.

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 at all, the description does real work: it discloses that the call is a read, that it returns an 'effectively unlimited' determination and a balance in addition to the raw allowance, and it flags the payment model ($0.005 USDC on Base via x402), which is critical operational context an agent must know before invoking. It stops short of describing failure behavior for non-contract tokens or malformed addresses.

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 return semantics are front-loaded and the cost note is short and actionable. The first sentence is a dense four-item list, but every item 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 simple 3-parameter read with no output schema, the description supplies the return shape and the payment requirement, which is what an agent needs to decide and call. Minor gaps: it does not explain how amounts are formatted (raw base units vs decimals) or how the 'spendable right now' figure is derived.

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 all three parameters already carry descriptions ('Address that granted the approval', 'ERC-20 contract on OP Mainnet', 'Address allowed to spend'). The description adds no syntax, format, or role nuance 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 the specific resource (ERC-20 allowance), the exact chain (OP Mainnet), and enumerates the returned facts: allowance amount, unlimited-approval flag, owner balance, and currently spendable amount. The chain qualifier cleanly separates it from eth_/base_/arbitrum_/polygon_erc20_allowance siblings.

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 chain scoping implicitly tells the agent to pick this variant for OP Mainnet rather than another chain's allowance tool, but there is no explicit when-to-use/when-not-to-use statement, no mention of prerequisites (e.g. token must be a contract), and no named alternative for other chains.

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 burden and does disclose key non-obvious behavior: the call is paid ($0.005 USDC on Base via x402), the ETH/USD conversion source is Chainlink, and the historical ranking is computed from the service's own 10-minute samples over 7 days. It does not state data freshness/timestamp semantics or whether the ranking window is rolling, which would round out a read-only but metered 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?

A single dense sentence that front-loads the primary data (gas conditions) before the derived analytics and the price. It is slightly run-on with three 'and/plus' joins, but nearly every clause names a distinct returned datum, so little is wasted.

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, no annotations and no parameters, so the description must describe the payload — and it does, field by field, including the pricing note. Remaining gaps are structural (response shape/units of the ranking percentile, freshness) rather than missing essentials for calling a zero-argument 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?

Zero parameters, so the baseline is 4 and there is no schema semantics to add. The description instead spends its words on output contents, which is the useful place given the empty input 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 and chain ('Current OP Mainnet gas conditions') and enumerates exactly what is returned: block number, base fee, gas price, priority fee, transfer cost estimates, 7-day ranking, and cheapest UTC hour. The chain qualifier distinguishes it from the sibling gas-price tools (base_gas_prices, eth_gas_prices, arbitrum_gas_prices, polygon_gas_prices) without needing 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 implied by the content listing — an agent can infer this is for checking Optimism gas before sending a transfer — but there is no explicit 'use this when / don't use this when' framing and no mention of the sibling alternatives for other chains. The cost note ($0.005 USDC) is a useful decision input for a paid tool but is not framed as a selection criterion.

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 add real context: the $0.02 USDC x402 payment on Base, the pool venues it samples (Uniswap v3 / Velodrome deepest pools), and the caveat that launch data appears only 'when we recorded it'. It still omits failure behavior for tokens without deep pools, rate limits, and whether results are cached or real-time.

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-loaded with the core purpose and packed with useful detail; every clause carries information (venues, fields returned, launch data, price). It is a single dense semicolon-chained sentence, which costs some parseability, but there is little waste.

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, so the description properly enumerates the return contents: USD size, side, wallet, transaction, buy/sell volume, net flow, top wallets, and optional launch history. Combined with the disclosed x402 cost, an agent has enough to call it and interpret results; only error/edge-case behavior 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 coverage is 100%, so the schema already documents all four parameters including ranges and defaults. The description reinforces the semantics of the look-back window ('last N minutes') and the size filter ('largest trades'), but adds no syntax, format, or edge-case guidance beyond what the schema supplies — 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 and resource — a whale/large-trade tracker for an ERC-20 on OP Mainnet — and scopes it to the token's deepest WETH/USDC pools on Uniswap v3 or Velodrome. That is enough for an agent to distinguish it from siblings like optimism_token_snapshot (token metrics) or optimism_new_pools (pool discovery) 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 by the content (recent buy/sell flow and top traders over a look-back window), and the x402 pricing note hints at a paid, on-demand call. However, there is no explicit statement of when to prefer this over optimism_token_snapshot, optimism_new_pools, or token_risk_check, and no exclusion conditions.

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 metadata is fetched from external storage (IPFS, Arweave, HTTPS, inline data URI), that the owner field only applies to ERC-721 (ERC-1155 has no owner), and that the call costs $0.008 USDC on Base via x402 — a prerequisite an agent must satisfy before invoking. It stops short of describing failure modes for unresolvable URIs or malformed metadata.

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 enumerating return fields followed by a short payment sentence — front-loaded and free of filler. The enumeration is long but every item is a distinct return field an agent would otherwise have to discover by calling.

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 compensates by listing the returned fields and their shapes (owner only for ERC-721, image as browser-loadable URL). Combined with the payment prerequisite, an agent has enough to decide and call. Minor gap: no statement of behavior when a token does not exist or metadata is unreachable.

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 both parameters are described with patterns, so the schema does the heavy lifting. The description adds only the constraint that `contract` must be an OP Mainnet collection; it says nothing new about tokenId formatting or edge cases.

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 (fetch ERC-721/ERC-1155 token metadata) and enumerates exactly what comes back: collection name, current owner, token URI, decoded metadata JSON, and image URL. The chain scope ('on OP Mainnet') cleanly separates it from the eth_/base_/arbitrum_/polygon_nft_metadata siblings without needing to name them.

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 chain qualifier implicitly tells an agent to pick this tool only for OP Mainnet tokens, which is the primary routing decision among the five nft_metadata siblings. However, there is no explicit when-to-use/when-not guidance, no mention of what to do for unsupported chains, and no note that this is a paid call versus the free-looking 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses the $0.01 USDC x402 cost, indicates the output is factual rather than advisory, and implies a read-only snapshot. It does not explicitly state read-only status or rate-limit behavior, but the paid-read nature is clear.

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 first sentence front-loads the core purpose and return contents; the two short follow-up sentences add useful caveats about opinion-free output and cost. The long enumerated sentence is dense but each listed field helps an agent understand what the snapshot provides.

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?

Because there is no output schema, the description must explain return values, and it comprehensively lists risk score, token metadata, ownership/renouncement status, proxy detection, bytecode findings, and market data. For a one-parameter paid snapshot tool, an agent has enough context 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?

There is only one parameter and schema description coverage is 100%, so the schema already documents that it expects a token contract address on OP Mainnet. The description reinforces the ERC-20/OP Mainnet scope but adds no meaningful syntax or constraint 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?

The description gives a specific verb/resource: a rug-check and due-diligence snapshot of an ERC-20 token on OP Mainnet. It lists the exact dimensions returned, making it clearly distinct from generic siblings such as optimism_contract_info or wallet-oriented tools.

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 use case is implied by 'Rug check and due-diligence snapshot,' and the description clarifies that it returns facts only, with no buy/sell opinion. However, it does not explicitly say when to use this instead of related siblings like token_risk_check or optimism_contract_info.

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 does disclose the meaningful behavioral trait that the call costs $0.005 USDC on Base via x402, which an agent needs before invoking. It does not cover read-only guarantees, latency, caching, or failure modes, so it is adequate but not rich.

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: the first front-loads the return contents, the second carries the payment constraint. No filler, no repetition of the name or title.

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 compensates by listing the returned fields, and it discloses the x402 cost. For a one-parameter lookup this is nearly complete; only error/empty behavior and the exact response shape remain 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?

There is a single parameter with 100% schema description coverage, including a regex pattern, so the schema fully specifies its meaning and format. The description adds nothing beyond it, which is the baseline expectation for a fully documented single-parameter tool.

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 (an OP Mainnet transaction) and enumerates exactly what the summary contains: status, block/time, sender/recipient, ETH value, gas, method selector, and decoded ERC-20 transfers. The network prefix in the name plus the explicit 'OP Mainnet' in the text separates it from the eth_/base_/arbitrum_/polygon_ variants, though it never states that distinction outright.

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?

There is no guidance on when to choose this over a sibling like optimism_wallet_balances or optimism_token_snapshot, nor any mention of prerequisites or error conditions (e.g. what happens for an unknown hash). Usage is only implied by the tool name and the input.

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 present, the description carries the load and does meaningful work: it discloses the payment cost ($0.005 USDC on Base via x402), that data is read live from OP Mainnet, and that only explicitly listed tokens are returned (no auto-discovery). It stops short of covering failure modes such as invalid or non-ERC-20 token addresses.

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 the core capability front-loaded and the cost/chain constraints trailing. Every clause contributes something an agent could not infer from the schema alone.

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 (balances formatted with symbol and decimals) and the payment requirement. That covers what an agent needs to call it, though error handling for malformed or non-ERC-20 token entries is left 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 coverage is 100%, so both parameters are already documented in the schema. The description restates the 20-token cap and the ERC-20 nature of the listed tokens but adds no syntax, ordering, or edge-case detail beyond what the schema provides, so 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?

The description names a specific resource (native ETH plus up to 20 listed ERC-20 balances) on a specific chain (OP Mainnet), so the verb and scope are unambiguous. It does not explicitly separate itself from the near-identical sibling optimism_wallet_profile or optimism_token_snapshot, which keeps it from 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 implied by the phrasing 'tokens you list' and 'read live from OP Mainnet', which suggests a spot-check read. There is no explicit when-to-use guidance, no statement of when to prefer optimism_wallet_profile or optimism_token_snapshot, and no preconditions beyond the address.

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 the paid x402 model with a precise price ($0.005 USDC on Base) and enumerates the returned fields, which is critical since there is no output schema. It is implicitly a read-only lookup. Minor gaps remain — no statement about behavior for a non-existent/EOA address (partial result vs error) or any rate/response-time notes.

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-loaded with the core purpose in the first clause, followed by a dense but scannable enumeration of returned data and a separate cost sentence. No filler, though the return-field list is long; it earns its length because no output schema exists to carry that 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?

For a one-parameter read tool with no annotations and no output schema, the description covers purpose, chain scope, return surface and payment cost — everything needed to decide to call it and interpret results. The remaining gap is failure semantics for invalid or non-contract addresses and any note on output format beyond field names.

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 the single address parameter carries its own description and a ^0x[0-9a-fA-F]{40}$ pattern, so the schema already does the work. The description adds only that the address must be on Polygon PoS, which is marginal beyond the schema. Baseline 3 applies for a fully documented single parameter.

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 ('Identify what lives at') plus the exact resource scope (a Polygon PoS address) and enumerates the concrete outputs: EOA vs contract, EIP-7702 delegation, ERC-20/721/1155, name/symbol, proxy implementation and admin, bytecode size, nonce and POL balance. The chain qualifier cleanly separates it from eth_contract_info, base_contract_info and the other *_contract_info siblings, and the descriptive scope separates it from polygon_wallet_profile / polygon_token_snapshot.

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 enumeration of outputs strongly implies when to reach for it (address classification and token/proxy inspection on Polygon), but no explicit when-to-use or when-not-to-use statement exists and no sibling is named as an alternative. An agent must infer that polygon_wallet_profile is the choice for transactional history and polygon_token_snapshot for token-market data rather than learn it here.

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 must carry the behavioral load, and it discloses a genuinely non-obvious trait: the call costs $0.005 USDC on Base via x402. It also makes the response content predictable. It stops short of covering failure modes or latency, but the paid-call disclosure is the piece an agent most needs before invoking.

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 purpose and returned fields, with the pricing note second. No filler, no repetition of the tool name, and nothing that could be cut 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?

No output schema exists, so the description appropriately enumerates the four returned values, and all three required params are covered by the schema. What's missing is minor: the actual response shape/field names and behavior on invalid or unapproved pairs.

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 all three parameters are documented (owner grants, token is the ERC-20 contract, spender is allowed to spend). The description's 'a spender may transfer from an owner' restates those roles in allowance terms but adds no format or constraint 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?

Names the exact resource (ERC-20 allowance), the chain (Polygon PoS), and enumerates what is returned: allowance amount, unlimited-approval flag, owner balance, and current spendable amount. The chain qualifier cleanly separates it from eth_erc20_allowance, base_erc20_allowance and the other chain-prefixed siblings without needing 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: phrases like 'whether the approval is effectively unlimited' hint at a token-approval security review, but there is no explicit when-to-use, no exclusion, and no pointer to alternatives such as polygon_wallet_balances or polygon_token_snapshot. An agent must infer whether to call this or a broader balance/snapshot tool.

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