x402-data-gateway

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

With no annotations provided, the description takes full responsibility for safety and behavior disclosure. It clearly states that catalog queries use no credentials or payments, and that the optional fetch is DNS-pinned, same-origin, redirect-free, size-capped, and read-only. It also frames results as point-in-time evidence, not demand or future proof.

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 dense sentences with no filler. It front-loads the core purpose, then handles the conditional optional parameter, and closes with crucial safety and limitation context. 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?

Given the tool's complexity (6 params, no output schema, no annotations), the description covers a lot: purpose, optional mode, safety constraints, and high-level result interpretation. It stops short of specifying exact result fields or error conditions, but the provided limitation statement ('not demand, runtime truth, or future-rank proof') gives useful outcome framing.

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 describes all parameters at 100% coverage, so baseline is 3. The description adds operational meaning by explaining when surfaceAudit should be set and by characterizing what expectedPriceUsd measures ('exact-price drift'), extending beyond the schema's raw 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 starts with a specific verb ('Measure') and names the exact resource ('one service') and scope ('ten public machine-service discovery views'). It enumerates distinct outputs like brand-blind rank, source-family coverage, and expected-route presence, clearly distinguishing this from broad sibling tools like read or scan.

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

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

The description implies when to use the tool: to audit a service's discoverability across discovery views. It gives explicit conditional usage for the optional surfaceAudit parameter ('set surfaceAudit only when...'), but it does not name alternative sibling tools or state when not to use this tool.

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 carries full burden. It clearly states 'Historical read-only evidence; no transaction simulation, wallet, signing, or broadcast,' a significant behavioral disclosure. It also notes 'before off-chain costs' as a return nuance.

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: purpose, alternatives, and safety limitations. Every sentence earns its place, front-loaded with the main action. No filler.

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

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

For a 1-param tool with no output schema, the description lists every output category (repaid/seized assets, protocol-oracle valuation, gross incentive, health window, gas) and clarifies context (Base, successful transaction). Complete enough without an output schema.

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

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

Single parameter transactionHash is fully documented in schema (pattern + description). Description adds no extra parameter-specific semantics beyond the schema, so baseline 3 applies.

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

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

Specific verb+resource (Reconstruct one successful Base Morpho PreLiquidation transaction) with explicit list of outputs. It distinguishes from siblings by naming alternatives for different use cases.

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 alternatives provided: 'Use morpho_market_underwrite for current market risk, morpho_position for a current borrower, or morpho_protection for a future protection plan.' 'Historical read-only evidence' also signals when not to use this tool.

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. It discloses that the tool is read-only, does not involve wallet, signing, broadcast, or custody, and that approval/call outputs are unsigned templates. This is strong behavioral context for a calculation-only tool, though it doesn't mention rate limits or authorization requirements.

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 pack in purpose, output composition, alternatives, and safety, with zero fluff. The structure front-loads the core function and progressively adds context, making it 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?

Despite having no output schema and no annotations, the description explains what the plans include (bounded asset amount, expected stressed health factor, evidence basis, unsigned templates), confirms read-only behavior, and guides tool selection. This fully covers a moderate-complexity 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?

Schema description coverage is 100%; all four parameters include detailed descriptions, defaults, and constraints. The description adds minimal additional meaning by referencing 'selected collateral-price shock and target health factor,' but the schema already handles parameter semantics thoroughly, 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 uses a specific verb 'Calculate' and identifies the resource as 'two alternative protection plans for one Base Morpho borrower,' clearly naming the two plan types (partial repayment or added collateral). It distinguishes itself from sibling tools by explicitly naming alternatives like morpho_position, morpho_market_underwrite, and morpho_preliquidation_replay.

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 when to use this tool versus alternatives: 'Use `morpho_position` for diagnosis without an action plan, `morpho_market_underwrite` for market-wide risk, or `morpho_preliquidation_replay` for a completed historical event.' This provides clear selection 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 provided, so the description carries the full burden. It discloses that the tool uses 'caller-supplied cost and selection assumptions plus dated platform evidence', returns specific metrics, and explicitly states it does not perform claims, bids, payments, or submissions. This gives a clear sense of side-effect-free decision making. However, it does not mention any potential side effects like data fetching or caching, nor does it state whether the process is deterministic or stochastic.

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 core purpose and followed by outputs and exclusions. Every phrase adds value: the arrow format conveys decision options, and the output list is concise. The final 'No claim...' sentence is a valuable clarification without 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 tool has 13 parameters, 3 enums, no output schema, and no annotations, the description provides a functional overview but is relatively brief. It explains what the tool returns and what it does not do, which is sufficient for initial understanding. However, it does not elaborate on the decision branches (deterministic vs verify-first) or how the platform evidence is sourced, which would be helpful for full completeness. Still, the core is 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 baseline is 3. The description adds a slight semantic grouping by referencing 'caller-supplied cost and selection assumptions' which maps to input parameters like hourlyCostUsd, computeUsd, selectionProbabilityPct, etc., but it does not provide additional detail beyond the schema. No parameter clarification is needed since the schema already describes each parameter fully.

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 with a specific verb ('preflight') and resource ('agent work opportunity'), explaining it produces a decision among 'deterministic attempt, verify-first, or abandon'. It also lists concrete outputs (break-even probability, expected surplus, hard gates, source-linked evidence) and differentiates from action-oriented tools by noting 'No claim, bid, payment, or submission'.

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 context: when evaluating an agent work opportunity to decide whether to attempt, verify-first, or abandon. However, it does not explicitly mention when to use this tool over sibling tools (e.g., deep_audit, scan) or provide exclusions. The 'No claim, bid, payment, or submission' line hints that this is a pre-decision tool, but no explicit alternative guidance is given.

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 discloses the tool's safety posture: it uses no target credential, signs and sends no payment, follows no redirect, reads no response body, and does not establish trust or settlement reliability. This directly addresses behavioral traits that an agent must know, far exceeding typical descriptions.

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 serving a distinct function: purpose, alternative usage, and behavioral constraints. No filler or redundancy. Front-loaded with the core purpose and immediately followed by actionable guidance and boundary conditions.

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 covers the tool's scope, exclusions, and implications. While no output schema exists, the mention of 'including URL and realm binding, expiry, and cross-protocol economic parity' hints at what the tool will return. It could be more explicit about the exact return structure, but the description provides enough context for an agent to form accurate expectations given the tool's preflight nature.

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 schema description for 'url' is already detailed, including the exact route requirement and rejection criteria. The main description reinforces these but introduces only marginal new meaning (e.g., 'before buyer authorization' and 'cross-protocol economic parity' are more about tool purpose than parameter semantics). Baseline 3 applies because schema carries the semantic load.

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

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

The description uses a specific verb ('Compare') and names both protocols (x402 and MPP) and the resource (one exact public HTTPS GET route). It also lists concrete comparison dimensions (URL and realm binding, expiry, cross-protocol economic parity) and distinguishes from a sibling tool by referencing 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?

Explicitly states when to use this tool (before buyer authorization) and provides a clear alternative: 'Use agent_discoverability_audit instead when you need to know whether catalogs rank or expose a service.' It also sets boundaries by specifying restrictions like no credential use and no redirect following.

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, the description carries the transparency burden. It discloses the scan's static nature, the specific red flags it detects (exfil sinks, obfuscation, credential reads, curl|bash), and the risk output values. It does not explicitly state side effects or limitations beyond 'public', but the key behaviors are well covered.

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, information-dense sentence. It includes the primary action, context, detection targets, and output risk categories without wasted words. Ideal conciseness.

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 only one parameter and no output schema, but the description covers the main return concept via risk levels. It could be more explicit about output structure or error cases, but for a simple scanning tool it is largely complete.

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

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

The only parameter 'repo' is fully described in the schema (public GitHub repo: owner/name or URL). The description repeats the 'public GitHub repo' aspect but adds no additional semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool performs a static supply-chain security scan of a public GitHub repo, with specific detection targets and risk classifications. This distinguishes it from sibling tools like deep_audit or extract by focusing on pre-install security 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 phrase 'before an agent installs/runs it' provides clear usage context, indicating the tool is for pre-install vetting. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for typical selection.

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

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

With no annotations, the description carries 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 carries full responsibility. It explicitly states this tool reads only public Base receipt and log data, reads no merchant ledger, and performs no wallet, signing, broadcast, custody, or execution action. This effectively discloses its read-only and non-mutating 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 three sentences, front-loaded with the core purpose, and contains no redundant information. The alternative tool reference and safety disclosures are concise and necessary.

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 well-scoped: it names the alternative, explains safety, and details the verification logic. However, it does not mention the return format or failure behavior (e.g., whether it returns a boolean or proof details), which is a minor gap given there is no output schema.

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. The description adds value by explaining how the parameters are used together in the verification process (matching receipt to recipient, amount, and optional payer), but it does not add per-parameter specifics 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 purpose: verifying a claimed canonical Base USDC settlement by matching a transaction receipt against expected recipient, amount, and optional payer. It uses a specific verb ('Verify') and distinguishes itself from sibling tools by explicitly referencing payment_offer_preflight as an alternative for unpaid offers.

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 usage guidance: use this tool after execution, and use payment_offer_preflight before authorization when inspecting an unpaid offer. It also clarifies that it only reads public Base receipt/log data, implying appropriate scenarios and 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 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses important constraints: accepts no credentials, counter values, wallet/resource IDs, signatures, transactions, or raw provider responses, and does not run provider tests. It does not explicitly describe output or side effects, but the 'evaluate' wording and detailed scope provide reasonable transparency for a read-only conformance assessment.

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

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

The description is compact and well-structured: three sentences each add a distinct value—purpose, sibling alternative, and specific capabilities/restrictions. No filler or redundant information, and it front-loads the core purpose before expanding.

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 complex tool with no output schema, but the description covers purpose, usage differentiation, detailed test scenarios, and input restrictions. It does not explain the return value, which would be helpful, but the rich description largely compensates for the missing output schema. The level of detail is high for a tool of this complexity.

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

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

Schema coverage is 100% for all 5 parameters, each with meaningful descriptions. The description restates global input restrictions (no credentials, counters, etc.) that align with the schema, but does not add new per-parameter semantics or examples beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool evaluates safe standardized observations from wallet policies tracking prior or concurrent requests. It distinguishes itself from the sibling wallet_policy_conformance by explicitly enumerating the stateful test scenarios it covers (sequential cumulative limits, signed-but-unbroadcast accounting, ABI extraction, etc.), making its purpose immediately clear.

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 usage guidance: it tells the agent to use wallet_policy_conformance instead for one-request action shape, method, chain, token, recipient, amount, and function controls. It also clarifies that this tool separately tests stateful behaviors and does not run the provider tests itself, 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?

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?

With no annotations provided, the description carries the transparency burden. It discloses that the tool 'Accepts no credentials, wallet IDs, signatures, transactions, or raw provider responses' and that it 'evaluates caller-supplied observations and does not run the provider tests itself.' This clearly communicates the safe, non-executing nature of the tool. Slightly more detail about output (e.g., what a conformance verdict looks like) would elevate it, but the current disclosure is strong.

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 four sentences, with the main action in the first sentence. Each subsequent sentence adds distinct value: usage context, input exclusions, and non-execution. No redundancy or filler; it is dense but readable.

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 complexity is moderate, with a detailed observations schema and no output schema. The description covers what it does, when to use it, what it rejects, and what it doesn't execute. It does not explain the return format, but for an evaluation tool this is a minor gap. Overall, it provides sufficient context for an 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?

Schema coverage is 100%, so baseline is 3. The description adds semantic value by emphasizing that observations are caller-supplied and that the tool rejects credentials, raw responses, etc. This reinforces the meaning of the 'observations' parameter and the overall safe-input contract, going beyond the schema's individual 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 allow, deny, and error observations from an agent wallet or delegated signer.' It clearly defines the tool's focus on policy conformance evaluation. This distinguishes it from sibling tools like wallet_enrich or deep_audit, which have broader or different scopes.

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: 'Use this after running a bounded provider policy test matrix.' It also articulates the purpose ('to distinguish explicit provider-policy enforcement from validation or generic provider failures') and what it does not do ('does not run the provider tests itself'), providing clear boundaries and indirect exclusion criteria.

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