x402-data-gateway

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

With no annotations, the description carries the full transparency burden and largely meets it: it discloses that catalog queries use no credentials or payments, that results are point-in-time evidence, and that materializationAudit avoids exact-resource materialization. The schema description also adds bounded same-origin fetches. It does not fully state side effects or rate limits, but 'bounded' and 'no credentials/payments' cover the main risk areas.

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 in the first sentence, followed by parameter-mode guidance and caveats. Every sentence contributes meaning, but the density of jargon (brand-blind rank, canonical-vs-alias, ERC-8004, Bazaar materialization) makes it heavy; appropriate for the domain but not light.

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 no output schema and no annotations, the description compensates well by explaining orchestration of runtimeUrl, expectedPriceUsd, surfaceAudit, materializationAudit, and the limits of the evidence produced. It does not describe the return shape or all combinations of parameters, but for a specialized audit tool it gives enough for an agent to select and call it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds valuable cross-parameter semantics: runtimeUrl takes precedence over expectedPriceUsd, surfaceAudit and materializationAudit each trigger specific audit scopes, and materializationAudit requires route and method. This goes beyond the individual parameter descriptions 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 opening sentence names a specific action ('Measure') and a precise resource: one service's discoverability across ten machine-service discovery views, with enumerated metrics like brand-blind rank, expected-route presence, and exact-price drift. This clearly differentiates the tool from siblings like agent_surface_budget_audit or seller_integrity_audit by focusing on listing and discovery 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 gives explicit conditions for optional behaviors: supply runtimeUrl to derive price from a live x402/MPP offer, set surfaceAudit for Agent Card/ERC-8004 checks, and set materializationAudit to distinguish Coinbase ineligibility. It also provides exclusions by stating results are not demand, seller trust, settlement, or future-rank proof, though it does not name alternative sibling 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does this unusually well by explicitly stating that the tool follows no redirect, calls no target tool, sends no credential or target payment, and returns no target schema, response body, or session identifier. These safety and side-effect disclosures are highly relevant for agent invocation.

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 every sentence earns its place: the first states the core action, the second routes to sibling tools, and the third covers safety and non-side-effects. It is front-loaded with the most important information and contains 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?

Given the tool has six parameters, an output schema, and no annotations, the description provides enough context for an agent to select and invoke it correctly. It explains purpose, alternatives, safety behavior, surface-selection semantics, and what will not be returned, while the output schema covers return-structure details.

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 input schema already documents all six parameters thoroughly. The description adds useful context about byte budgets and unselected surfaces, but it does not need to explain individual parameters; the baseline of 3 is appropriate when the schema carries the parameter-level detail.

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 ('Measure') and a precise resource: a public service's credential-free MCP tools/list, OpenAPI, or both discovery surfaces. It also names sibling tools and clarifies what this tool does not do, making it easily distinguishable from agent_discoverability_audit and seller_integrity_audit.

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

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

The description explicitly says when to use this tool ('before any tool call or target payment') and gives exact routing guidance: use agent_discoverability_audit for catalog reach and rank, seller_integrity_audit for a single operation's response contract, and this tool for byte budgets, heaviest definitions, and progressive-discovery fixes. It also states that unselected surfaces are not fetched or judged, which clarifies selection behavior.

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 full burden. It discloses exclusions (SameDayDesk-owned supply, unresolved routes), states it uses no credentials or wallet, sends no seller POST or payment, reads no paid response body, and returns only a query digest. This is strong behavioral disclosure, though it doesn't explicitly mention rate limits or error handling, but for a search tool this is quite thorough.

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 moderately long but every sentence provides value: it specifies sources, matching criteria, alternative tools, exclusions, and behavioral guarantees. The alternative tool list adds length but is crucial for usage guidance. 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?

Given 4 params with 100% schema coverage, output schema present, and no nested objects, the description is complete. It covers purpose, usage boundaries, exclusions, side-effect guarantees, and return nature. The output schema handles return values, so no gap there.

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 all four parameters, each with detailed descriptions including constraints and purpose. The description adds the context that 'query' is a capability intent and that 'requiredPaths' must be dotted success-response paths, but these are largely echoed in schema descriptions. Baseline 3 is appropriate since schema does 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?

Description clearly states it searches Agent402 and MPP for paid machine services that match capability intent and guarantee required JSON response paths. It names the specific resources and the filtering criterion, distinguishing it from sibling audit 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?

Explicitly names three sibling tools and specifies their use cases versus this tool: agent_discoverability_audit for measuring a known seller's catalog reach, seller_integrity_audit when a specific seller route is known, and payment_offer_preflight when an exact callable GET URL exists. This gives clear when-to-use versus when-not-to-use 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It proactively discloses: read-only operation ('read-only'), no site changes ('no site changes are made'), diagnostic nature of the score ('the score is diagnostic'), placeholders in the template ('The template contains placeholders for real data'), and a limitation ('does not guarantee AI citations'). These go well beyond a minimal description.

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 primary purpose. Every clause adds value: the first sentence defines scope and components, the second gives alternative directives and important caveats. There is no filler 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?

This is a composite tool (enrich + schemaforge) with no output schema, yet the description covers what the tool does, what it returns (gap analysis, JSON-LD template, diagnostic score), its limitations, and how it relates to siblings. Given the complexity, the description is complete enough for an agent to select and invoke the tool 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?

The input schema already documents all 3 parameters at 100% coverage. The description adds a little context (e.g., 'public business domain' and the mention of template placeholders) but does not materially enrich the meaning of individual parameters. Per calibration, baseline 3 is appropriate when 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+resource: 'Run one read-only AI-search-readiness audit for a public business domain.' It enumerates concrete components (company, technology, contact, DNS/email evidence, structured-data gap analysis, JSON-LD template) and explicitly distinguishes itself from sibling tools by directing users to 'enrich' for company facts only or 'schemaforge' for structured-data remediation only.

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 guidance is explicit: 'Use `enrich` for company facts only or `schemaforge` for structured-data remediation only.' This clearly states when to use this tool versus its alternatives. It also sets expectations with 'one read-only audit' and 'public business domain,' making the applicable scope unambiguous.

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

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

With no annotations provided, the description carries the full behavioral burden. It explicitly discloses that the tool uses public data only and makes no site changes, effectively communicating a read-only safety profile. It also describes the output as structured evidence, setting 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?

Three focused sentences: the first states the tool's action and output categories, the second gives precise alternatives, and the third clarifies the data scope and non-mutating nature. No filler, every sentence earns its place.

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

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

Despite lacking an output schema, the description enumerates the major output domains (identity, tech, social, contact, DNS, email-infrastructure, AI-readiness) and clearly situates the tool among siblings. This is sufficient for an agent to decide when to invoke it.

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 already provides a clear description of the 'domain' parameter with an example and a pointer to wallet_enrich. The main description reinforces the parameter but adds no new parameter-level semantics beyond what the schema already conveys, meriting the 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 a specific verb ('Inspect') and resource ('public company domain'), and enumerates the exact categories of evidence returned (identity, technology, social, contact, DNS, email-infrastructure, AI-readiness). It also distinguishes itself from siblings by naming schemaforge and deep_audit as alternatives.

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

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

Explicit guidance is provided: use schemaforge for JSON-LD templates/remediation diff, deep_audit when both outputs are needed, and the tool is scoped to public data with no site changes. This gives clear when-to-use and when-not-to-use 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 provided, the description carries the full burden of behavioral disclosure. It transparently states that JavaScript is not executed, redirects are followed, and SSRF, timeout, and response-size guards are applied. It does not mention the exact output format or error behaviors, but for a low-complexity fetch tool this is solid coverage beyond the obvious read-only nature.

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: two sentences. The first sentence lists the return content categories, and the second provides the alternative tool and salient behavioral guards. Every word adds value with no filler 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?

Given the low complexity (one required parameter, no output schema), the description fully covers the tool's purpose, output signals, alternative usage, and safety behaviors. It is complete enough for an agent to select and invoke the tool without missing critical information.

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 baseline is 3. The parameter description adds meaningful usage guidance by reiterating when to use extract vs. read and noting no JavaScript rendering, which goes beyond a mere type/format definition. This adds practical semantics for selecting the right 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 uses a specific verb ('Fetch') and clearly identifies the resource ('public HTTP(S) page') and the output (compact extraction signals: title, meta description, Open Graph/Twitter metadata, JSON-LD, headings, links, text excerpt, AI-readiness flags). It also distinguishes itself from the sibling tool 'read' by explicitly contrasting metadata/link inventory vs. full-body Markdown, which is strong 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 description explicitly states when to use 'extract' (need metadata, JSON-LD, headings, links, text excerpt) and when to use 'read' instead (need the page body as LLM-ready Markdown). This directly addresses the main alternative among siblings and gives clear decision criteria.

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 present, so the description carries the full transparency burden. It discloses that the tool is read-only, aggregates evidence from three independent sources, will present explicit disagreements, and will not produce an opaque score or execute a transaction. This is solid behavioral disclosure, though it could mention failure modes or cost implications of the multi-source evidence gathering, hence not 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?

The description is a single dense paragraph that front-loads the verb and resource, enumerates the evidence categories, then pivots to alternatives and behavioral constraints. Every sentence provides distinct value, though the long list of evidence types makes it somewhat heavy. Overall it is efficient and well-structured.

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 is complex (multi-source evidence for underwriting) and has no output schema, so the description must convey what the agent receives. It explains the evidence domains, the multi-source approach, and the output style (explicit disagreements, no risk score). It could be more explicit about the report's structure or format, but the description is complete enough for a knowledgeable agent 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?

The input schema covers the single `marketId` parameter completely (100% coverage) with a pattern and description. The description adds minimal semantic value beyond the schema: it clarifies that the market is on Base and that a single market is underwritten, but these are largely already implied or stated in the schema. Baseline 3 is appropriate when 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: 'Underwrite one Base Morpho market' and enumerates the exact evidence dimensions (configuration integrity, liquidity, utilization, concentration, borrower health bands, recent history, bad debt, PreLiquidation availability). It clearly distinguishes itself from siblings by naming the alternatives for one-borrower positions, protection plans, and historical replays.

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 when to use this tool (underwriting a whole market) and when not to: it directs the agent to `morpho_position` or `morpho_protection` for one borrower's current position/protection, and `morpho_preliquidation_replay` for a single historical event. It also sets expectations ('no opaque risk score or transaction action'), which guides invocation.

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 and clearly states 'Read-only; no wallet, signing, broadcast, or custody,' which is a key behavioral disclosure. It also adds context about direct-RPC verification and caller-selected stress scenarios, but does not fully detail edge-case behavior or response structure, 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 concise: a single dense sentence explaining purpose and outputs, followed by sibling comparisons and a safety note. No filler or redundancy; every sentence contributes 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 an inspection tool with two simple parameters and no output schema, the description covers the essentials: what it inspects, what it returns, how to choose alternatives, and safety. It is sufficiently complete for an agent to decide when and how to invoke it.

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 provides 100% coverage for both parameters (address, shocks), so the baseline is 3. The description adds meaning by referring to 'caller-selected collateral-price stress scenarios,' which clarifies the intent behind the `shocks` parameter beyond its raw schema description, earning a 4.

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 action ('Inspect one Base borrower across Morpho markets') and enumerates concrete outputs ('position balances, LTV, health factor, liquidation headroom, direct-RPC verification, and caller-selected collateral-price stress scenarios'). It also distinguishes itself from sibling tools by naming alternatives, making the purpose unmistakable.

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 gives when-to-use guidance: 'Use morpho_protection when you need exact repay or add-collateral amounts and unsigned transaction templates, morpho_market_underwrite for market-wide risk, or morpho_preliquidation_replay for one completed historical event.' It also notes the read-only nature, informing safe usage.

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 must carry the full burden. It explicitly states 'Historical read-only evidence; no transaction simulation, wallet, signing, or broadcast,' disclosing it is a safe read operation with no side effects. It also describes the inputs (receipt and exact block state) and outputs, providing a clear behavioral contract. No contradictions.

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, dense and front-loaded. The first sentence packs purpose and key output types; the second sentence gives alternative tool guidance and safety constraints. No fluff or repetition. Ideal for quick agent parsing.

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

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

With an output schema present, the description needn't detail return values. It covers purpose, usage boundaries, safety profile, and parameter context. For a read-only, single-parameter tool, this description is thorough and leaves no critical gaps for an agent to misinterpret.

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% (single transactionHash with description 'Successful Base transaction containing a Morpho PreLiquidate event'). The description adds the context that the tool uses the receipt and exact block state to reconstruct the transaction, providing extra meaning about how the hash is used. It also clarifies the hash must be for a successful transaction, reinforcing the schema. This goes beyond the schema, so a 4 is justified.

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 reconstructs a successful Base Morpho PreLiquidation transaction from its receipt and exact block state, listing specific outputs (repaid/seized assets, oracle valuation, incentive, health window, gas). It explicitly contrasts with sibling tools by naming morpho_market_underwrite, morpho_position, and morpho_protection for different use cases, distinguishing it from other Morpho tools and general transaction receipt 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?

Provides explicit guidance on when to use this tool (historical read-only evidence for past transactions) and when to use alternatives (current market risk: morpho_market_underwrite; current borrower: morpho_position; future plan: morpho_protection). Also states what the tool does not do (simulation, wallet, signing, broadcast). This is exceptional 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?

Description declares 'Read-only; no wallet signing, broadcasting, or custody' which covers external side effects, but lacks explicit statements about in-memory state mutation, though 'read-only' implies no state changes. No annotation exists to add credibility.

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?

Compact but dense description. It is structured with use-cases, alternatives, read-only note, template list. Not wordy, but rich.

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 output schema exists, and the description includes plan components (bounded asset amount, stressed health, evidence basis, ERC-20 approval plus Morpho stack). Context is given through sibling tool references and output/input schema, sufficient for a read-only calculation 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?

Parameter descriptions in the schema are substantive: address pattern, basis-point buffer meaning with default and range, target health with exclusive min and max, and collateral shock range with -10 example. No parameter details are in the description, but schema coverage is 100% and the encoding is clear.

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 ('Calculate two alternative protection plans for one Base Morpho borrower under a selected collateral-price shock and target health') and explicitly differentiates from sibling tools by naming the alternatives (morpho_position for diagnosis, morpho_market_underwrite for market-wide risk, morpho_preliquidation_replay for historical events).

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?

Provides explicit when-to-use guidance ('Use `morpho_position` for a diagnosis without a plan, `morpho_market_underwrite` for market-wide risk, or `morpho_preliquidation_replay` for a completed historical event') and states read-only constraints, wallet signing, broadcasting, custody.

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 non-mutating behavior ('No claim, bid, payment, or submission'), states inputs (caller assumptions, dated platform evidence) and outputs (probability, surplus, gates, evidence), giving a solid 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?

Three short sentences: purpose arrow, output summary, and side-effect disclaimer. Every sentence adds distinct value and the most important information is 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?

Given 13 parameters and no annotations, the description plus 100%-covered schema and output schema provide a complete enough picture. It could add example scenarios or failure modes, but it is not missing critical operational context.

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 has 100% parameter coverage, so baseline is 3. The description only adds aggregate context ('caller-supplied cost and selection assumptions', 'dated platform evidence') rather than per-parameter meaning, which is acceptable because the schema already documents every 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?

Description explicitly frames the tool as preflight analysis of an agent work opportunity, listing concrete outputs (break-even probability, expected surplus, hard gates, source-linked evidence) and a clear non-action boundary ('No claim, bid, payment, or submission'), which distinguishes it from action-oriented 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?

Clear context: use with caller-supplied cost and selection assumptions plus dated platform evidence before deciding among deterministic attempt, verify-first, or abandon. It excludes submission, claims, and payment, though it does not name 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 provided, the description fully discloses behavioral traits: it uses no target credential/signature/payment, follows no redirects, never reads the paid target body, and only reads a same-origin public OpenAPI document under a strict size cap. It also clearly warns that seller declarations are advisory and not proof of validity/trust/reliability.

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?

Though dense, every sentence carries critical information: purpose, usage contrast, safe-operation boundary, and advisory nature. It is front-loaded with the core action and then systematically covers constraints. 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 is fully sufficient for an agent to understand the tool's scope, limitations, and input expectations. It addresses all key aspects: exact route requirement, comparison dimensions, safety guarantees, and the advisory nature of results. The presence of an output schema further reduces the need to explain return values, and the description still outlines what evidence is gathered.

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

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

Schema coverage is 100%, and the description adds substantial meaning beyond the schema. For the url parameter, it explains that the route's unpaid challenge headers and OpenAPI declaration will be inspected. For the catalog parameter, it details exactly how the comparison is performed (across request, protocol, amount, network, asset, recipient, and expiry). This goes well beyond the raw schema descriptions.

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 ('Compare') and resource ('x402 and MPP payment challenges, terms, and seller-declared JSON success-response readiness') for a precise target (one exact public HTTPS GET route). It clearly distinguishes itself from siblings by explicitly naming agent_discoverability_audit as the alternative when catalog ranking/exposure is needed.

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 when to use this tool ('before buyer authorization'), what it covers (URL/realm binding, expiry, parity, OpenAPI evidence), and when not to use it (explicitly directing to agent_discoverability_audit for the alternative use case). It also clarifies what the tool does not do (no credentials, no redirects, no reading paid body).

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 well: it states the output is cleaned Markdown, that navigation/ads/scripts/header/footer/aside/form elements are dropped, that the markdown is capped at 40,000 characters, and that no JavaScript is executed. This gives the agent a realistic model of the tool's behavior without needing annotations.

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: first states core function and transformations, second points to an alternative, third states the two key constraints (cap and no JS). No filler or repetition; the information density is high and it front-loads the purpose.

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 one parameter and no output schema, this description fully covers inputs, outputs, transformations, limitations, and alternatives. The only potential missing piece is explicit return type, but the description says 'return its readable body as cleaned Markdown' which is sufficient.

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 covers the sole parameter (url) with a description that reproduces almost all details (public HTTP(S), needed as Markdown, no JS, truncation at 40k). Since schema coverage is 100% and the description does not add new detail beyond the schema, 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?

The description opens with a specific verb phrase 'Fetch a public HTTP(S) page and return its readable body as cleaned Markdown,' precisely identifying the action and resource. It also distinguishes itself from the sibling tool by noting 'Use extract instead when you need metadata...' so it avoids ambiguity.

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 names the alternative tool ('Use extract instead') and lists the conditions (metadata, JSON-LD, Open Graph/Twitter tags, link inventory) where that alternative is preferred. It also implicitly defines when to use this tool: anytime the readable body as Markdown is needed, especially for LLM 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 present, the description must reveal behavioral characteristics beyond what a machine would infer. It does provide safety-relevant behavior details: it flags specific risk signals (exfiltration sinks, obfuscation, credential reads, install-time curl|bash) and a tri-state risk verdict, giving the agent a reasonably complete behavioral picture of the scan.

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: three dense sentences, with semicolon-separated list of risk flags, and a clear risk-delimited output. 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?

The tool has an output schema defining the risk result and a modest single input parameter. The description does not fully specify whether the scan executes code locally, network-access requirements, or specific permissions. However, for a public-repo static scanner with a clear output score, this is largely a complete context.

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 documents the 'repo' parameter (owner/name or URL). The description adds only marginal context (that the repo must be public and is on GitHub), which is useful but not a transformative explanation of 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 uses a specific verb 'Scan' with a clear resource ('public GitHub repository') and temporal scope ('before an agent installs/runs it'), distinguishing it as a supply-chain security scanner rather than a general code-generation or procurement 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?

It clearly situates the tool's purpose: security scanning of public repos prior to install. However, it does not explicitly state when not to use it (e.g., for PRIVATE repos or after code execution) or name alternative tools, though the static-context makes the intended trigger scenario strong enough.

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 responsibility for behavioral disclosure. It does well by stating that the output is deterministic, contains placeholders requiring replacement, makes no site changes, and does not guarantee AI citations. This goes beyond basic read/write hints. A slight gap is not covering rate limits or authentication, but for an analysis tool this is sufficient.

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, each serving a distinct purpose: purpose and outputs, alternative guidance, and caveats. It is front-loaded with the main functionality and has no redundant or filler 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 tool with no output schema and moderate complexity, the description gives a solid overview of expected outputs (template, diff, fixes) and key constraints (placeholders, no site changes). It does not describe the structure of the diff or fixes, but the core usage context is well covered.

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 each parameter. The description adds no additional parameter-level detail beyond what the schema provides (e.g., the `site` fetchability and JS behavior are already in the schema). Therefore, 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 uses a specific verb ('Analyze') and clearly identifies the resource ('public business site') and the outputs ('JSON-LD template', 'gap diff', 'ranked fixes'). It also distinguishes itself from the sibling tool `deep_audit` by noting when to prefer the alternative, making the purpose unmistakable.

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 provides an alternative tool ('Use `deep_audit` instead') and states the condition for switching (when company, technology, contact, and DNS/email evidence are needed). This gives clear when-to-use and when-not-to-use guidance, which is rare and highly useful for an agent.

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 must carry the behavioral disclosure burden. It does so thoroughly: GET performs live verification of x402 and MPP economics, POST performs static-safe OpenAPI analysis and sends no target request, and no target credential, signature, payment, or retained schema/body/query values are used.

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 well-structured: usage triggers first, then operation details, then exclusions and safety guarantees. Every sentence adds value and no words are 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 tool with six params, no annotations, and no output schema, the description is remarkably complete. It covers when to use it, what GET vs POST do, which sibling to choose instead, and what data is not used or retained, leaving the agent well-equipped 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?

Schema description coverage is 100%, so the schema already documents every parameter. The description adds useful behavioral context, such as 'live x402 and MPP economics' and 'static-safe OpenAPI contract analysis,' but it does not materially expand the per-parameter semantics 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 is specific: it audits one exact paid GET or POST seller route against buyer-required JSON success paths. It names the resource, verb, and scope, and explicitly distinguishes itself from sibling tools payment_offer_preflight and agent_discoverability_audit.

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 first sentence gives explicit trigger conditions: after a buyer integration fails, after a seller changes a paid route, or before the next paid retry or release. It also names alternatives and the exact conditions under which to use them instead.

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 full responsibility for behavioral disclosure. It explicitly states the tool 'reads only public Base receipt and log data' and 'performs no wallet, signing, broadcast, custody, or execution action,' which is strong transparency for a verification 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 sentences, each earning its place: purpose and matching criteria, alternative tool guidance, and safety/read-only behavior. The description is front-loaded and free of filler.

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

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

Given the tool's moderate complexity, the presence of an output schema, and 100% schema parameter coverage, the description sufficiently covers purpose, usage context, behavioral constraints, and parameter intent. No critical context 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 description coverage is 100%, so the baseline is 3. The description adds the notion of 'exact' matching and 'optional payer,' but it does not materially enrich parameter semantics beyond the schema's own descriptions.

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 ('Verify') with a precise resource ('claimed canonical Base USDC settlement') and defines the matching criteria (successful transaction receipt, exact recipient, atomic amount, optional payer). This clearly differentiates it from generic receipt tools like transaction_receipt and from preflight tools like payment_offer_preflight.

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

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

It explicitly states when to use the tool ('after execution') and names a specific alternative for a different scenario: 'Use payment_offer_preflight before authorization when you need to inspect an unpaid x402 or MPP offer instead.' This gives clear contextual 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?

With no annotations provided, the description takes on full responsibility. It discloses what is returned (success/failure status, slot, block time, fee, deltas), what is excluded (raw instructions and logs), and explicitly states what the tool does NOT do ('no wallet, signing, broadcast, custody, or execution action'). This is strong behavioral disclosure, though it could additionally address error handling for non-finalized signatures.

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 yet information-dense. The first sentence states the core action and outputs, the second provides usage context and an alternative, and the third clarifies exclusions and non-actions. Every sentence serves a purpose 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?

The tool has five parameters (one required), no output schema, and no annotations, so the description must carry significant weight. It does so by covering purpose, specific return fields, exclusions, and chain specificity. However, given the complexity of the return data, a more detailed description of the response format would improve completeness.

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 all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by relating parameters to the settlement verification use case ('Supply recipient, amount, and optional payer when an exact settlement claim must be verified') and indicating that mint defaults to canonical USDC, enhancing the schema's dependency notes.

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 'Inspect one finalized Solana mainnet transaction signature' and lists the specific return values (status, slot, block time, fee, SPL-token owner deltas, canonical USDC deltas). It distinguishes itself from the sibling `transaction_receipt` by explicitly noting that it is for Base or 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?

The description provides explicit guidance on when to use this tool: 'Supply recipient, amount, and optional payer when an exact settlement claim must be verified' and for alternative chains, 'use transaction_receipt for Base or Ethereum.' It also clarifies exclusions and non-actions, offering clear 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 carries the behavioral burden and does well by stating it 'accepts no credentials, counter values, wallet or resource IDs, signatures, transactions, or raw provider responses' and 'does not run the provider tests itself.' It does not explicitly state whether the operation is read-only or has side effects, but the evaluative framing and input restrictions strongly imply a safe, non-mutating test.

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, then the alternative tool, then the distinguishing test scope and input constraints. Every sentence earns its place, and the structure is easy to scan.

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 five required parameters, no annotations, and an output schema, the description is complete: it explains what the tool evaluates, how it differs from the sibling, what inputs are forbidden, and what it does not do. The output schema presumably covers return values, so no further return-format detail is needed.

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 meaningful context by enumerating the tested behaviors (sequential cumulative limits, signed-but-unbroadcast accounting, ABI extraction, concurrent oversubscription, counter-reference failure, application serialization) that map to the observation `case` enum. It also reinforces the schema's rejection of unsafe inputs, adding value beyond the parameter descriptions.

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: 'Evaluate safe standardized observations from wallet policies that track prior or concurrent requests.' It clearly distinguishes this tool from its sibling by naming `wallet_policy_conformance` and contrasting the one-request controls 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?

The description explicitly directs users to `wallet_policy_conformance` for one-request action shape, method, chain, token, recipient, amount, and function controls, while stating this tool is for stateful cumulative, concurrency, and serialization tests. This provides clear when-to-use and when-not-to-use 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?

With no annotations provided, the description fully discloses behavioral scope: what is returned (normalized status, block time, gas/fees, decoded transfers), what is excluded (raw logs), and what actions are NOT performed (wallet, signing, broadcast, custody, execution). This transparency goes beyond a simple 'inspect' and sets proper expectations for a read-only inspection 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 with a clear front-loaded purpose, followed by an alternative and exclusions. Every sentence contributes value without redundancy or fluff, maintaining high information density in a compact structure.

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?

Despite having no output schema, the description enumerates the main returned categories, states exclusions, and gives a fallback for deeper verification. For a 2-parameter, 1-required tool, this is complete and leaves minimal ambiguity for an agent deciding whether to invoke it.

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 described clearly. The description adds little beyond the schema for parameters; it restates the hash as 'mined' but doesn't add format or semantic details beyond what the schema's pattern and descriptions provide. According to the rubric, baseline 3 is appropriate when 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 clearly states 'Inspect one Base or Ethereum transaction hash' and enumerates specific outputs (normalized success/revert status, block time, gas and fee fields, decoded ERC-20 Transfer events, canonical USDC transfers). It distinguishes itself from `settlement_proof` by naming the alternative, making the tool's specific role unambiguous.

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

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

The description explicitly provides usage guidance with a direct alternative: 'Use `settlement_proof` instead when you must verify an exact canonical Base USDC recipient, amount, and optional payer claim.' It also clarifies exclusions ('Raw logs are excluded') and non-actions ('performs no wallet, signing, broadcast, custody, or execution action'), giving clear when-to-use and when-not-to-use 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?

No annotations are provided, so the description carries the burden. It discloses the read-only nature ('Read-only public chain data; no wallet action or custody') and lists the evidence types returned, which sets expectations. It does not mention error handling or edge cases, but for a single-address inspection tool, this is fairly transparent.

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

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

Three sentences, each earning its place: main purpose, usage guidance, and safety disclosure. The description is front-loaded with the operation and scoped output, making it efficient and easy to parse.

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 one parameter and no output schema, the description provides a comprehensive summary of what the tool does, what it returns, when to use it, and its safety profile. It is slightly lacking in explicit output format details or potential failure modes, but is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% and the parameter description already explains the address and directs to use wallet_enrich vs enrich. The tool description adds that it 'Inspect[s] a public Base or EVM address' and returns a profile, but it does not introduce new parameter-level semantics; the schema already carries the burden.

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 'Inspect' with a clear resource ('public Base or EVM address') and enumerates the output components (EOA/contract type, token holdings, NFT metadata, proxy evidence, activity, derived profile label). It also distinguishes from sibling `enrich` by identifier type, making the purpose unmistakable.

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 'Use `enrich` for a company domain; the two tools accept different identifiers and return different evidence.' This gives clear when-to-use guidance and directly contrasts with the closest alternative. The read-only note further implies a safe analysis use case.

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 disclosure burden. It clearly states 'Accepts no credentials, wallet IDs, signatures, transactions, or raw provider responses; it evaluates caller-supplied observations and does not run the provider tests itself,' which conveys the tool's safe, non-executing nature. It does not describe output behavior, but an output schema exists to cover that.

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 dense sentences: the first states the core action and object, the second provides usage timing and input restrictions. Every sentence earns its place with no filler 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?

For a tool with five required parameters, a nested observations schema, and an output schema, the description covers purpose, usage context, and input safety constraints well. It does not need to explain return values because an output schema exists; the only minor gap is not explicitly contrasting with the stateful sibling 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 meaningful descriptions for all five parameters, so the baseline is 3. The description adds value by emphasizing that observations are safe, standardized, caller-supplied, and that raw provider responses and credentials are rejected, which reinforces the profileId and observations constraints.

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: 'Evaluate safe standardized allow, deny, and error observations from an agent wallet or delegated signer.' It clearly distinguishes itself from siblings like stateful_wallet_policy_conformance by stating it evaluates caller-supplied observations and does not run provider tests itself.

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

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

The description explicitly says 'Use this after running a bounded provider policy test matrix' and explains the analytical goal: distinguishing provider-policy enforcement from validation/generic failures and separating execution shape from allowlisting. It does not name alternative tools or provide when-not-to-use guidance, but the usage context is clear.

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