Tereno on Base

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

With no annotations provided, the description carries the full transparency burden. It discloses the cost model ($0.001–$0.002 USDC via x402), the shared cache behavior (reuse discounts, wallet credits), and the specific return fields. It does not mention failure modes or authorization requirements, but for a simple read-only call with zero parameters, it provides adequate behavioral disclosure.

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 main purpose and return values, followed by pricing and sharing details. It is slightly verbose in the second sentence but every part adds value (cost, sharing mechanics). Overall, it is well-structured and not 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 simple tool with no parameters and no output schema, the description is remarkably complete. It lists the returned data (block number, timestamp, base fee, gas fees), explains pricing, and describes the shared-cache credit system. There is no ambiguity about what the tool does or what the agent should 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?

The tool has zero parameters, and the description explicitly states 'no parameters required,' which reinforces the empty schema and clarifies that no input is needed. This goes beyond the baseline for zero-parameter tools, adding direct confirmation of the tool's parameter-free nature.

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 immediately states the tool's purpose: retrieving the current state of the Base network, including latest block number, timestamp, base fee, and suggested gas fees. It clearly distinguishes itself from sibling tools, which focus on contracts, tokens, and other on-chain operations, by specifying 'Base' and the chain snapshot data.

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 provides clear context on when to use the tool: whenever a lightweight, parameter-free call is needed to get Base's current chain state. It also mentions cost implications and the shared-cache behavior, which informs economic decisions. However, it does not explicitly name alternative tools or exclusion scenarios, so it does not fully meet the bar for 'explicit when/when-not/alternatives'.

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

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

With no annotations provided, the description takes on the full burden. It discloses the paid-per-call nature, cost range, shared-answer economics, and the specific dimensions checked. It does not describe return format or potential side effects beyond credits, but the main behavioral traits are clearly conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the core purpose, and every sentence adds value. The first sentence states the question and action; the second explains pricing and sharing. There is no redundancy or 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 single-parameter tool, the description covers purpose, detection scope, and cost model. However, there is no output schema or mention of what the tool returns (e.g., boolean vs. change details), leaving an important gap for an agent deciding how to use 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?

The input schema already provides 100% coverage with a clear description for the address parameter. The tool description adds the 'Base contract' and 'previous Tereno observation' context but does not introduce significant new parametric meaning 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 clearly states the tool's function: comparing a Base contract against its previous observation and detecting specific change types (bytecode, EIP-1967 implementation, admin, paused-state). This distinguishes it from sibling tools like contract_guard or contract_interface, which focus on other aspects.

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 the usage context ('Did this Base contract change since I last checked?') but does not explicitly mention when to prefer this over alternatives or provide exclusions. Sibling tools are not referenced, so the guidance is not fully explicit.

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 the tool checks executable code, detects proxy/pause signals, returns a bounded verdict, and explains the x402 payment model with cost range and sharing credits. This exceeds basic transparency, though it doesn't detail the exact verdict format.

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 relatively concise and front-loaded with the core question and checks. The payment sentence is slightly long but adds useful behavioral context about cost and sharing, so it earns its place. No fluff.

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 1-parameter tool with no output schema, the description covers the key aspects: what it checks, what it returns ('bounded action verdict'), and cost behavior. It is functionally complete, though a bit more detail on the verdict values would push it to 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?

The input schema already provides 100% coverage with a clear description for the single 'address' parameter. The tool description adds no additional parameter-level semantics beyond what the schema states, so the baseline 3 is appropriate.

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

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

The description states a specific verb ('Check') and resource ('Base contract') while detailing exact checks (executable code, proxy/pause signals) and a 'bounded action verdict'. This clearly distinguishes it from sibling tools like contract_interface or transaction_intent_guard by focusing on safety assessment.

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 use before interacting with a contract, but it does not explicitly state when to use this over alternatives or mention exclusions. The 'safe to interact with?' framing gives context, but no explicit 'use this instead of...' guidance is provided.

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 transparently discloses cost ($0.001-$0.002 USDC), network (Base), sharing/credit mechanics, and the 'bounded check' nature. However, it does not explicitly state read-only status or potential side effects.

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 three sentences with no fluff. Pricing and sharing details are relevant but slightly expand length; overall, it is efficient and front-loaded.

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?

The tool's purpose and cost are well explained, but there is no output schema and the description does not indicate what the response looks like. An agent would be uncertain about the return format, which is a notable gap for a detection 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?

The schema fully covers the single 'address' parameter (100% coverage) with a description matching the tool's scope. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description clearly states the tool detects ERC-20, ERC-721, ERC-1155, ERC-165, and EIP-1967 proxy slots with a specific verb ('Detect'). This distinctly separates it from sibling tools like contract_change or token_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?

There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for interface detection, but it does not state when not to use it or how it compares to sibling contract 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 disclosure burden. It reveals key traits: no immediate credit, bounded and non-transferable credit, and conditional release only if the same wallet later settles the capability. This is useful, though it doesn't mention if the pledge is irreversible or if it has other side effects.

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 sentences, front-loaded with 'Free market-signal pledge,' and every clause adds value. It is concise without sacrificing key behavioral 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 tool with only two well-documented parameters and no output schema, the description provides sufficient context about the pledge's purpose and credit behavior. It lacks guidance on return values or failure conditions, but these are less critical for a simple declarative 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% for both parameters, so the schema already documents wallet and capability thoroughly. The description adds some context (e.g., 'same wallet' reinforces the wallet parameter) but doesn't provide additional syntax or format details beyond the schema, warranting a baseline score.

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 it is a market-signal pledge for declaring a capability you would pay for, with a specific conditional credit mechanism. This distinguishes it from sibling tools like chain_snapshot or token_metadata, which have different purposes.

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 does not explicitly state when to use this tool or when to avoid it. It implies a usage for signaling demand but offers no guidance on alternatives or exclusions, leaving the agent to infer context.

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 fully carries the transparency burden. It discloses per-call pricing ($0.001–$0.003 USDC), privacy policy (never cached/shared/resold), and the public-scope limitation. The schema adds recomputation behavior for expired artifacts. This is substantial behavioral context.

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 with the purpose placed first, followed by pricing and privacy. Every sentence earns its place with no fluff or 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?

The tool has one parameter with a rich schema, and the description covers purpose, return value types, pricing, privacy, and recomputation. It does not detail a specific output schema (none exists), but the enumerated return items (provenance, field validity, recomputation inputs) are adequate.

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 artifactId, including pattern and recomputation note. The description adds no new syntax but reinforces the reuse context with cost and privacy details. Baseline 3 is appropriate since the schema already fully documents the 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?

The description clearly states the tool returns machine-readable provenance, field validity, and recomputation inputs for a shared Base artifact, framed by the question 'Can this public Tereno artifact be reused?' This specific verb+resource combination distinguishes it from sibling tools like tereno_catalog and tereno_price.

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 gives clear context on when to use this tool (to check reusability of a public Tereno artifact) and adds the schema hint that the artifact ID comes from another agent. It does not explicitly exclude other tools or name alternatives, but 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?

The description discloses that the tool is free to use ('Free.') and explicitly lists the type of information it returns (capabilities, prices, validity, sharing). Without annotations, these disclosures provide essential behavioral context for a read-only catalog, though it does not explicitly state it is read-only.

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 exceptionally concise, using just three short sentences to convey the tool's purpose and content. 'Free.' front-loads the most critical information, and every subsequent phrase adds value, 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?

For a zero-parameter, no-output-schema informational tool, the description provides complete context: what the catalog covers, cost of using it, and guidance to read it first. There is no missing information that would prevent an agent from using this tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema coverage (empty schema), the description appropriately focuses on what the tool returns rather than parameter details. It adds meaningful context about the content of the catalog, fulfilling the baseline score of 4 for parameterless tools.

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 identifies this tool as Tereno's full capability catalog, including answers, price tiers in USDC on Base, validity duration, and sharing status. It distinguishes itself from sibling tools like tereno_price and tereno_receipt by serving as the overarching reference before any payment-related action.

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 instruction 'Read this before paying for anything' explicitly tells the agent when to use this tool—prior to any payment-related operation. It implies that other tools should be used after consulting this catalog, providing clear contextual guidance without naming specific 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 burden of behavioral disclosure. It states the tool is free, non-binding, does not reveal a wallet, and explains the hit/partial/miss tier semantics. This covers the essential behavioral traits for a pricing tool, though rate limits or auth are not mentioned.

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 concise and well-structured: four short sentences, each adding meaningful information—cost, purpose, tier semantics, and value interpretation. No fluff or 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?

The description comprehensively explains the return tiers (hit/partial/miss) without an output schema, and covers the tool's purpose and safety. Minor gaps exist around error handling or invalid inputs, but for a simple pricing tool, the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage, describing all four parameters with types and formats. The description adds little beyond 'one specific input,' so the schema already provides the necessary parameter semantics.

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

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

The description clearly states the tool's purpose: it provides an indicative price and reuse tier for a specific input, distinguishing it from sibling tools that perform actual operations. The title reinforces this as a cost-check tool.

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 before committing to an operation, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool is 'Free' and details the returned information (capability, version, cache tier, price paid, on-chain settlement). The verb 'look up' implies a read-only operation, but it does not explicitly state side-effect-freedom or require authentication. Still, it provides useful behavioral 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?

Two sentences, front-loaded with 'Free' and the core purpose. Every sentence contributes value – the first describes what it does, the second specifies when to use it. No wasted words.

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 tool with no output schema, the description adequately lists the result fields (capability, version, cache tier, list price, credit, paid price, on-chain settlement). It fully explains the tool's purpose and context. Minor gaps like not-found behavior do not significantly impede understanding.

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 already covers the single parameter 'invocationId' with description 'Invocation id from a receiptUrl.' The tool description does not add further meaning about the parameter beyond referencing 'settled invocation' in the purpose. Baseline 3 is appropriate since schema coverage is 100%.

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 starts with 'Look up what a settled invocation actually charged' – a specific verb and resource. It clearly distinguishes this tool from siblings like tereno_price (for quotes) and tereno_catalog (for catalog data) by focusing on settled receipts/billing verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the intended use: 'Use it to check that a call you or another agent paid for was billed the way it was quoted.' This gives a clear when-to-use signal. It does not explicitly mention when not to use it or name alternatives, but the use case is specific and actionable.

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 burden of behavioral disclosure. It goes beyond basic expectations by disclosing per-call payment, cost variation based on cache availability, credit for producing cached answers, and block-level freshness. This is strong transparency for a simple read 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?

The description is three sentences: a clear opening question, a statement of operation and outputs, and a concise cost/caching explanation. Every sentence carries useful information and there is no redundant fluff.

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 tool without an output schema, the description is quite complete. It lists the returned fields (name, symbol, decimals, total supply), mentions block-level freshness, and explains pricing and shared-cache behavior. Exact return formatting is not specified, but the core functional contract is clear.

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 already provides 100% coverage of the single 'address' parameter with a pattern, example, and description. The tool description repeats that it reads from a Base token address but adds no new semantic detail beyond what the schema already 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 opens with a clear question and then states 'Read a Base token's name, symbol, decimals and total supply', giving a specific verb, resource, and fields. This clearly distinguishes it from sibling tools such as contract_interface or chain_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 description clearly implies the use case: obtain Base token metadata in one call. It adds cost and caching context (x402, $0.001-$0.003 USDC, shared answers) that helps decide when to use it. However, it does not mention alternatives or when not to use it, so it lacks explicit 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, the description carries full burden. It discloses the paid nature (x402, $0.005 USDC), privacy guarantees (never cached/shared/resold), and that the unsigned transaction stays with the paying wallet. It also outlines the safety checks performed. This goes beyond basic operation but does not fully detail failure modes or response formats, so 4 rather than 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?

The description is two sentences, front-loaded with the key question. It packs many capabilities into a single list without excess wordiness. The cost and privacy details are valuable but add length; still, every sentence earns its place. Slightly dense, so 4.

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 the tool's complexity (simulation, safety checks) and lack of output schema, the description explains what it does and key operational aspects (cost, privacy). It does not specify the return format or how safety verdicts are communicated, but the high-level behavior is sufficiently clear for an agent to invoke it appropriately. This is a strong effort, slightly incomplete on response shape, hence 4.

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 provides 100% coverage with clear descriptions for all four parameters (to, data, from, value), including defaults and patterns. The tool description adds little beyond what the schema already states, so it meets but does not exceed the baseline for schema-heavy parameter semantics.

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

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

The description opens with a clear question 'Is this transaction safe to sign?' and then enumerates specific behaviors: classify intent, simulate execution, estimate gas, infer deltas, flag scams/unlimited approvals, and inspect target changes. This strongly differentiates it from sibling tools like contract_guard or chain_snapshot by focusing on transaction safety assessment before signing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states 'Before signing on Base' which provides clear context for when to use the tool. It implies a pre-signing safety check but does not explicitly mention alternatives or exclusions. Still, the context is unambiguous enough to guide appropriate use.

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

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

With no annotations, the description carries full burden. It discloses cost ($0.001–$0.005 USDC), x402 payment on Base, reuse/sharing behavior, and that the wallet earns a bounded credit. It does not mention any destructive or modifying behavior (it's a read/transform operation) but covers financial side effects and caching, which is substantial.

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 three sentences, front-loaded with the core purpose, and each sentence adds a distinct fact: what it does, caching benefit, and cost structure. No extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with no output schema, the description covers the primary behavior, output format (Markdown with resolved links/citations), caching, and pricing. It lacks details on error handling or exact return shape, but it is largely sufficient for an agent to decide and invoke the 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% with clear descriptions for both url and wallet. The description adds some context about wallet roles (payment and earning credit) but doesn't go beyond the schema in terms of parameter syntax or constraints, so a 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 clearly states the tool transforms a public web page into bounded, LLM-ready Markdown with resolved links, citations, and a content-addressed artifact. The verb 'turn' and resource 'public web page' are specific, and it distinguishes from sibling tools which focus on contracts, chains, tokens, and evidence.

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 the tool is for converting web pages to Markdown for LLM use and mentions reuse to avoid repeated costs. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions (e.g., not for private pages) in the description—though the schema rejects private/local targets.

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