YRUZ x402 tools

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

Beyond the annotations (readOnly, idempotent, non-destructive, open world), the description discloses the 50-link parallel cap, the per-call 0.01 USDC price via x402, that invalid input is refused before payment, that failed runs are never charged, and that missing payment returns PaymentRequired. That is substantive behavior an agent cannot infer from structured fields.

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

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

The core purpose and scan mechanics are front-loaded in the first sentence, followed by pricing and failure semantics. The trailing free-sample hint and HTTP endpoint line are mildly promotional overhead but still actionable.

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

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

With no output schema, the description still characterizes the return payload (status code, redirect target, response time, broken/redirected/healthy summary), and it covers payment and error paths. Only minor gaps remain, such as timeouts or how redirects are followed.

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

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

Schema description coverage is 100%, and the schema already documents url, max (1-50, default 30) and scope. The description only echoes the 50-link ceiling and adds no syntax, format or interaction detail 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?

States a specific verb and resource ('Find broken links on a web page') and then specifies the mechanism: fetch, collect internal and external links, check up to 50 in parallel. This is clearly separable from siblings like url_safety_check, link_preview and site_audit without opening a schema.

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

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

Usage context is implied by the scope/parallelism detail, and the payment and invalid-input behavior is spelled out, but there is no explicit statement of when to pick this over site_audit or url_safety_check, nor any exclusion 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds the material facts an agent cannot infer: cost (0.01 USDC), the x402 payment precondition, that no payment yields a PaymentRequired response, that invalid input is rejected before charging, and that failed runs are never billed. Those cost and failure-mode disclosures are exactly the behavioral context that matters here.

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

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

Front-loads the resource and the returned fields before the pricing mechanics, and no sentence is filler. It is slightly padded by the long parenthetical field lists ('LinkedIn, X, GitHub, Facebook, Instagram, YouTube ...') and the full HTTP URL example, which could be tighter.

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

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

There is no output schema, yet the description effectively documents the return payload field-by-field, and it covers the payment and error path that governs a successful call. For a single-parameter enrichment tool, nothing an agent needs to invoke it correctly is missing.

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

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

Only one parameter with 100% schema coverage, so the schema already documents it fully, including that URLs and emails are accepted. The description echoes that flexibility but adds no format, normalization, or validation detail beyond the schema, so it lands at the baseline.

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

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

States a specific verb+resource ('Company enrichment from a domain or email in one call') and then enumerates the concrete payload: name, description, logo, socials, emails/phones, email provider, tech stack, schema.org data, domain age. This is far more specific than a name restatement and lets an agent judge fit immediately.

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

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

Gives concrete use cases ('For lead qualification, KYB and CRM enrichment') and points to get_example for a free sample answer, plus an HTTP alternative. It never says when NOT to use it or why to pick it over a sibling like domain_intel, which likely overlaps on domain data, so it stops short of full routing guidance.

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

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

Annotations only cover safety (readOnly, idempotent, openWorld); the description adds substantive behavior beyond that: 60 s cache, Binance/Jupiter fallbacks, 0.002 USDC x402 pricing with no account or API key, invalid input rejected before payment, failed runs never charged, and PaymentRequired returned without payment. This is exactly the non-obvious operational context an agent needs.

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?

Purpose and identifier forms are front-loaded in the first sentence, then returns, then cost/safety terms. Density is high and nearly every clause carries information, though the free-sample and HTTP-URL tail is auxiliary rather than essential.

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

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

With no output schema, the description compensates by enumerating the returned fields (price, 24h change, high/low, market cap, volume, rank, source). For a 2-parameter read-only tool, the pricing, caching and failure semantics leave nothing important unexplained.

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 a real constraint not present in the schema: the 25-asset cap. It also restates the accepted identifier forms (ticker vs. Solana mint) and names example quote currencies beyond the schema's parenthetical.

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

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

States a specific verb and resource ('live prices ... for up to 25 assets') and enumerates accepted identifier forms: CoinGecko id, ticker symbol, and Solana mint address. An agent can tell this apart from sibling tools like crypto_trending or solana_token_check without opening the schema.

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

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

Gives clear usage context: batch up to 25 assets in one call, use get_example for a free sample, and an equivalent HTTP endpoint. It does not explicitly say when to prefer crypto_trending or solana_token_check instead, so the sibling routing is implied rather than stated.

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

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

Annotations already cover read-only, idempotent, open-world, non-destructive, but the description adds material economics and failure behavior that annotations cannot express: 0.003 USDC per call via x402 on Base or Solana, no account or API key, invalid input refused before payment, failed runs never charged, and a PaymentRequired response when unpaid. That is exactly the extra context an agent needs before committing to a paid call.

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

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

The scope enumeration is front-loaded in the first sentence and the payment and sample-lookup details follow in a logical order. It is longer than typical, but nearly every clause carries either scope or payment information an agent would otherwise have to probe for.

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 optional parameter, no output schema, and strong annotations, the definition covers what remains: what data comes back, what payment is required, where the HTTP equivalent lives, and how to get a free sample. Nothing blocking a correct first call is missing.

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

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

Schema coverage is 100% and the single limit parameter is already documented as "items per list, 1-20 (default 10)", so the schema does the heavy lifting. The description only echoes this indirectly through the sample URL (limit=10) and does not clarify that limit applies per list rather than in total, so it adds little 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?

Names a concrete verb and a rich set of resources: most searched coins, top 24h gainers/losers among the 250 largest, global market cap and BTC dominance, and last-hour trending Solana tokens with price/liquidity/organic volume. That scope cleanly separates it from siblings like crypto_price (single asset quote) and solana_token_check (token due diligence).

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

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

The framing "what the crypto market is doing right now" tells the agent this is the market-overview call rather than a single-asset lookup, and it explicitly routes to the sibling get_example for a free preview before paying. It stops short of naming when to prefer crypto_price or solana_token_check instead, so no true exclusion 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?

Annotations already declare readOnly/idempotent/non-destructive, but the description adds a lot of information the agent could not otherwise know: 0.01 USDC pricing via x402, no account or API key, invalid input refused before payment, failed runs never charged, and an x402 PaymentRequired response without payment. Nothing here contradicts the read-only 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?

Front-loaded with the capability summary, then payment terms and the sample/HTTP pointers in a logical order. It is dense and packs pricing, sampling and transport into one paragraph, but each element carries information an agent needs.

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

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

For a single-parameter read-only tool with no output schema, the description covers what comes back (scored report with every issue and its fix), what it costs, how payment works, and how to preview results for free. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the schema itself documents that a URL or email is also accepted, so the description need not repeat it. The description adds no syntax or format detail for the single domain parameter beyond the HTTP example URL, 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?

Opens with a specific verb+resource ('Domain intelligence in one call') and enumerates exactly what is covered: DNS records, email security stack, RDAP registration data, and TLS certificate, plus a 0-100 score. An agent can distinguish it from site_audit, url_safety_check or company_enrich without opening any schema.

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

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

Gives concrete use cases ('vetting a vendor, a sender or a lead') and points to get_example for a free sample before committing money. It does not explicitly name when to prefer a sibling such as url_safety_check or site_audit, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety burden is light. The description still adds real value by disclosing that the payload is a stored, real recording rather than a live invocation — a fact not derivable from annotations and important for interpreting freshness.

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, no filler, with the 'free/recorded preview' hook front-loaded and the parameter behavior immediately after. Every clause carries information.

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

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

For a one-optional-parameter read tool with no output schema, the description covers purpose, both invocation modes, and output provenance. It could say slightly more about how large or what form the recorded answer takes, but nothing essential is missing.

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

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

Schema coverage is 100% and already names the 'tool' parameter with an example. The description goes beyond it by explaining the omitted-parameter behavior (lists all paid tools with prices) and giving multiple concrete name examples, which the schema lacks.

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

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

States a concrete verb and resource: returns a real recorded answer from any paid YRUZ tool so the caller can preview output. This clearly distinguishes it from the paid sibling tools themselves (web_extract, site_audit, solana_token_check), which are named as inputs rather than competitors.

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 frames the use case (inspect output before paying) and the two modes: pass a tool name for a sample, or omit it to list all paid tools with prices. It does not explicitly say when to switch to the actual paid tool, but the 'before you pay' framing strongly implies the boundary.

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?

Goes well beyond the annotations by disclosing price (0.003 USDC), payment rail (x402 on Base/Solana, no account/API key), failure semantics (invalid input refused before payment, a failed run is never charged), and the PaymentRequired response without payment. It also gives a free-sample path via get_example and the HTTP equivalent.

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?

Capability is front-loaded in the first sentence, then pricing and payment behavior follow. The pricing, sample-call, and HTTP-endpoint sentences are longer than strictly necessary but each carries information an agent needs before invoking a paid tool.

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

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

With no output schema, the description supplies the full list of return fields, and for a paid tool it fully covers cost, payment flow, and failure/charging behavior. Nothing an agent needs in order to call and pay correctly is missing.

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

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

Schema description coverage is 100% for the single required `url` parameter, so the schema already carries the semantics. The description adds only that any URL is accepted, not format/validation details, which matches the baseline 3 for a fully documented schema.

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

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

The description opens with a specific verb+resource ("Link preview of any URL") and enumerates the returned fields (title, description, Open Graph/Twitter fields, favicon, oEmbed, JSON-LD), so the agent knows exactly what it produces. It does not explicitly contrast with the closest siblings such as web_extract or url_safety_check, which is the only gap.

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

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

It states a clear use case ("render rich links or to check how a page will look when shared"), which is a real context signal for selection. It stops short of naming when-not-to-use or pointing to alternatives like web_extract, so it is strong but not exhaustive.

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?

Beyond the readOnly/idempotent annotations, it discloses the monetization and failure model: 0.002 USDC per call via x402, invalid input refused before payment, failed runs never charged, and a PaymentRequired response without payment. That is exactly the context an agent needs before committing to a paid call.

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

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

Purpose is front-loaded and the return contents are enumerated tersely with units. The pricing/payment explanation and HTTP mirror URL are longer than strictly necessary but still earn their place for a paid endpoint.

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

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

With no output schema, the description adequately describes the return payload in prose and covers cost/payment behavior. Only minor gaps remain, such as freshness of the fee snapshot or response shape 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 coverage is 100% and the single optional `account` parameter is fully documented in the schema; the description adds nothing about it. Baseline 3 is appropriate when the schema carries the 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?

States a specific resource (Solana priority fee levels, USD transfer/swap cost, Base gas price and base fee, ERC-20 transfer cost) with concrete units, so the agent knows exactly what comes back. No sibling tool covers fees, and the description makes that scope explicit.

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

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

"Use it to set fees that land without overpaying" gives a clear intended context, and the free-sample reference (get_example) routes the agent for a preview. It stops short of naming when-not-to-use or an explicit alternative, but no sibling overlaps.

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

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

Annotations already establish read-only/idempotent/non-destructive, and the description adds a lot on top: exact price (0.01 USDC), the x402 payment path (USDC on Base or Solana, no account or API key), that invalid input is rejected before payment, failed runs are never charged, and that an unpaid call returns PaymentRequired. That is precisely the billing and failure behavior an agent cannot infer from 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?

Dense and front-loaded: coverage list first, then scoring output, then price/payment, then escape hatches. The trailing full HTTP URL with percent-encoding is slightly noisy for an MCP caller, but everything else earns its place.

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

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

For a one-parameter read-only tool with no output schema, the description still explains the return shape (0-100 scores per area with concrete fixes), the payment/error states, and a free-sample path. Nothing an agent needs before calling 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?

There is a single parameter with 100% schema description coverage, so the schema already carries the semantics. The description adds only an HTTP-form example URL with the query string; otherwise it does not explain accepted URL formats or domain normalization, so the baseline of 3 applies.

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

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

Opens with a specific verb+resource ("Website audit in one call") and then enumerates exactly what is checked: TLS, security headers, redirects, HTTP/2/3, compression, SEO tags, AI-agent readiness. That enumeration also separates it from narrower siblings like url_safety_check, uptime_check, and broken_links, which each cover only one slice.

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?

"In one call" implies this replaces the per-check siblings when a full picture is wanted, and it explicitly routes to get_example for a free sample. It does not, however, state when to prefer url_safety_check or uptime_check instead, so the exclusions are left implicit.

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

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

Annotations already declare read-only and idempotent behavior, but the description adds substantial context: per-call cost (0.005 USDC), x402 payment mechanism (no account/key), pre-payment validation, no charge on failure, and the x402 PaymentRequired response without payment. It also points to a free sample via get_example. This goes well beyond structured 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?

The description is front-loaded with the core purpose and return contents, followed by pricing, sample, and HTTP alternative. It is efficient and well-structured, though the HTTP URL adds slight length without being essential for tool invocation.

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 complexity of a paid financial data tool with no output schema, the description fully covers what is returned (symbol, name, amount, price, value, total, NFT count), payment flow, error handling, and a free sample path. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (address, min_usd) are already documented in the schema. The description does not add format details or validation rules beyond the schema, and min_usd is not mentioned in the description. Baseline 3 is appropriate when schema carries the 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 states a specific resource—a Solana wallet's full token portfolio valued in USD—and lists exactly what is included (SOL, fungible SPL/Token-2022 balances, total value, NFT count). It distinguishes itself from simpler siblings like wallet_balance by emphasizing completeness and sorting.

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 'One call instead of dozens of RPC reads' implies usage for comprehensive portfolio retrieval, but the description does not explicitly name when to use this tool versus siblings such as wallet_balance or solana_token_check. No exclusions or alternative routing are provided.

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

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

Annotations already cover safety (readOnly, idempotent), but the description adds substantial context they cannot: the 0.005 USDC x402 payment model, that invalid input is refused before payment, that failed runs are never charged, and that a PaymentRequired response is returned without payment. It also names the underlying data sources (Helius, Jupiter), which matters for trusting the risk 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?

Dense but front-loaded: the capability list comes first, followed by return value, pricing, and fallback channels. The pricing/payment sentences are long and would benefit from trimming, but each carries operational information an agent needs before calling.

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

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

There is no output schema, yet the description explains the return shape ('0-100 risk score with every red flag explained') and the failure mode (PaymentRequired). For a single-parameter read tool, nothing an agent needs in order to call it correctly is left out.

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

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

Only one parameter and schema coverage is 100%, so the schema already fully documents 'mint'. The description implies the argument via the example HTTP URL but adds no format nuances (e.g., base58 validation, wrapped vs native mints). Baseline 3 is appropriate when the schema does the work.

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

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

States a specific verb and resource ('Safety check of any Solana token') and enumerates exactly what is inspected: authorities, holder concentration, liquidity, organic volume. This clearly separates it from siblings like solana_portfolio or solana_tx_explain, which serve different token-adjacent questions.

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

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

Gives a concrete usage trigger ('before an agent buys it') and routes agents to get_example for a free sample answer. It does not explicitly exclude or compare against siblings such as crypto_price, which overlaps on price data, but the pre-purchase safety framing provides 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?

Goes well beyond the readOnly/idempotent annotations: discloses pricing (0.003 USDC per call), the x402 payment mechanism with no account or API key, that invalid input is refused before payment, that failed runs are never charged, and that an unpaid call returns PaymentRequired. These are exactly the runtime traits an agent needs to avoid surprise failures.

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

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

Front-loads the capability and output contents in the first two sentences, then layers on commerce and error behavior. The free-sample pointer and HTTP endpoint URL are useful but push the tail toward promotional weight; nothing is strictly wasted, but it is on the long side.

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

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

With no output schema, the description compensates by listing the decoded fields the agent will receive, plus status, fee and balance deltas. Combined with the payment and failure semantics, an agent has everything needed to call it and interpret the result.

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

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

Only one parameter with 100% schema coverage, so the schema already carries the meaning. The description adds a real base58 signature in the example URL that implicitly illustrates the expected format, but never states format or constraints explicitly.

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

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

States a specific verb and resource (decode a Solana transaction into plain language) and enumerates the exact output fields: type, program/DEX, transfers with token symbols and amounts, SOL balance changes, fee and status. This clearly separates it from siblings like solana_portfolio (holdings) and solana_token_check (token risk).

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

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

Gives concrete use cases — 'confirm a payment or audit what a wallet did' — which tell the agent when to reach for it. It does not explicitly name an alternative tool or state when not to use it, so it stops short of a full routing rule.

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

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

Annotations already declare readOnly, openWorld, idempotent and non-destructive, but the description adds the commercial and failure semantics that matter: 0.003 USDC per call via x402, no account/API key, invalid input refused before payment, failed runs never charged, and PaymentRequired returned without payment. That is exactly the context an agent needs before invoking a paid endpoint.

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

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

The description is front-loaded with the core check and then adds payment/error behavior and a sample pointer, all of which earn their place. It is dense and slightly run-on, and the duplicated raw HTTP URL is arguably unnecessary for an MCP caller, which keeps it from a 5.

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

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

For a two-parameter tool with no output schema, the description covers the return fields thoroughly, explains pricing and payment failure behavior, and points to get_example for a free sample. An agent has enough to decide, call, and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds semantic context by listing the keyword among checked outputs and saying the keyword 'must appear on the page,' and by noting that the url may be a URL or domain. That modest extra meaning lifts it above baseline.

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

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

The description states a specific check ('Is it up, right now, from the internet') and enumerates exactly what is reported: HTTP status, final URL, DNS/connect/TLS/TTFB timings, HTTP version, size, content type, server, cert days left, and keyword match. That is far more precise than siblings like site_audit or url_safety_check, and an agent can tell which question this tool answers.

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

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

It gives a clear when-to-use context: 'For monitors, deploy checks and agents that must not act on a dead site.' That condition selects it over observational siblings such as domain_intel or link_preview. It does not name an explicit alternative or exclusion, so it stops short of a 5.

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

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

Far beyond the annotations: it discloses the return shape (0-100 score, safe/caution/dangerous verdict, per-signal explanations), the heuristic/no-blocklist limitation, the paid model (0.005 USDC via x402 on Base or Solana, no account/API key), the failure semantics (invalid input refused before payment, failed runs never charged), and the unpaid path (x402 PaymentRequired). That is exactly the operational context annotations cannot carry for a paid, open-world 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?

Front-loaded with the decision question, then the checks, then the result contract, then payment logistics — a logical order. It is dense but long; the pricing/refund sentences are necessary for a paid tool, though the trailing 'same tool over HTTP' URL and sample-answer pointer add bulk beyond core selection value.

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

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

No output schema exists, and the description fully compensates by describing the return values (score, verdict, explained signals). Combined with the payment and error-path disclosure, an agent has everything needed to decide whether to call it and to interpret the response.

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

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

There is a single required parameter with 100% schema description coverage, which sets the baseline at 3. The description adds an example URL and an equivalent HTTP calling form, but nothing new about the parameter's semantics (e.g. whether bare domains without scheme are accepted, or how redirects affect the input).

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

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

States a specific verb and resource ('checks the final site' behind a link) and enumerates exactly which signals are inspected (RDAP domain age, TLS, punycode, brand impersonation, drainer patterns), which separates it cleanly from siblings like site_audit, link_preview and domain_intel. The framing question 'Should an agent open, sign or pay this link?' pins the decision it supports.

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

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

The opening question establishes a clear use context (pre-click / pre-signature / pre-payment vetting) and it names the x402 payment path plus a sibling (get_example) for a free sample. It stops short of explicit exclusions — it never says to use site_audit for page content or domain_intel for registry data 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?

Beyond the read-only and idempotent annotations, the description discloses the x402 payment model, price per call, invalid-input refusal before payment, no charge for failed runs, and the PaymentRequired response when unpaid. These are important behavioral details an agent needs before invoking a paid 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 core purpose and return values are front-loaded, and the description is generally efficient. It includes some extra operational details such as the free sample call and HTTP URL, which are useful but not strictly necessary for MCP tool selection.

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

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

There is no output schema, but the description explains the return contents well: USDC amount, SOL/ETH fee balance, account existence, and x402 affordability. It also covers payment failure and invalid-input behavior, making it complete enough for an agent to call it correctly.

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

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

Schema coverage is 100% and both parameters are documented in the input schema, so the schema already carries most parameter semantics. The description adds workflow context for the optional amount parameter by explaining that it tests whether the wallet can pay a given x402 price, but does not add format or edge-case detail beyond that.

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

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

The description states a specific verb and resource: reading USDC and gas balances for any Solana or Base address. It also names exactly what is returned, including USDC amount, SOL/ETH fee balance, account existence, and x402 affordability. This clearly distinguishes it from sibling tools like network_fees or solana_portfolio.

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

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

It gives clear usage context: an agent can check its own funds or a counterparty before paying. It does not explicitly name when not to use it or compare directly against alternatives, but the use case is 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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description goes well beyond them by disclosing the paid x402 flow, the PaymentRequired response without payment, that invalid input is refused before payment, and that failed runs are never charged. It also names the upstream data sources, giving the agent confidence about provenance.

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

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

It is dense but front-loaded: capability first, then inputs, then data sources and payment terms. Every sentence carries information, though the pricing/x402 mechanics and the HTTP URL could be trimmed for a single-call tool without loss of essential meaning.

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

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

With no output schema, the description explicitly enumerates the return contents (current fields, hourly, 7-day highs/lows/rain, alerts), notes US-only alerts, and covers the payment/error path. Nothing an agent needs to call or interpret the tool correctly is missing.

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

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

Schema description coverage is 100% — q, lat and lon are each documented with type and range. The description's 'Place by name or coordinates' restates the schema's required-unless-lat/lon relationship without adding format or syntax detail, so the baseline 3 applies.

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

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

The description names a specific resource (weather for any place on Earth) and enumerates the exact payloads returned: current conditions, hourly 48h, 7-day forecast, and US alerts. No sibling tool covers weather, so it is trivially distinguishable, and the scope (metric/imperial, name or coordinates) is stated up front.

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

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

It states the two input modes ('Place by name or coordinates') and clarifies the payment precondition plus the invalid-input/no-charge behavior, which tells the agent when a call will succeed. There is no explicit when-not-to-use or alternative-tool routing, but no sibling overlaps on weather, so little is left to inference.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds substantial context beyond them: a 5-redirect limit, supported content types, the x402 pricing and payment rails, the guarantee that invalid input is refused pre-payment and failed runs are never charged, and the exact PaymentRequired response when unpaid.

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

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

Front-loaded with the core capability and return payload in the first sentence; the rest is dense but each clause carries operational value (limits, pricing, failure semantics, free sample, HTTP equivalent). The trailing example URL is slightly boilerplate but genuinely useful for the paid path.

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

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

No output schema exists, yet the description enumerates the returned fields (title, description, language, canonical URL, author, publish date, headings, links, images), so an agent knows what comes back. Payment, failure, and format behavior are all covered for a 3-parameter tool.

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

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

Schema coverage is 100%, so url, links and max_chars are fully documented in the schema with defaults and ranges. The description adds only indirect hints (Markdown output, redirect handling) rather than meaning beyond the structured fields, so the baseline 3 applies.

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

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

States a specific verb and resource ('Fetch any public web page') plus the exact output shape ('main content as clean Markdown') and the metadata fields returned. An agent can distinguish this from link_preview or url_safety_check by the payload, though no sibling is named explicitly.

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

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

Gives a clear usage context ('Built for agents that need to read or cite the web'), the accepted content types, and an escape hatch for a free sample via get_example. It stops short of explicit when-not-to-use or a direct comparison to the preview/safety siblings.

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

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

Annotations already cover read-only/idempotent semantics, and the description adds the costly-to-discover facts: it performs a live unpaid call against the target plus fetches discovery files, charges 0.005 USDC via x402 with no account or API key, refuses invalid input before payment, never charges a failed run, and returns PaymentRequired when unpaid. Those are exactly the billing and failure traits an agent needs before invoking.

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

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

One front-loaded paragraph that leads with what is checked and what is returned before pricing, which is the right order. It is dense but nearly every clause earns its place; the trailing HTTP URL and pricing repetition are slightly promotional overhead.

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

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

There is no output schema, so the description carries the return burden and does so: networks, USD prices, and 'every problem with its fix.' Combined with payment handling, refusal-before-payment, and the free-sample pointer, an agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100% and both parameters carry descriptions, so the schema does the heavy lifting and a 3 baseline applies. The description adds nothing about `url` or `method` semantics beyond an example query string, though it does implicitly show a full-URL shape.

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

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

States a specific verb and resource ('Validate any x402 endpoint') and then enumerates exactly what is validated: the 402 challenge in both v2 header and v1 body form, every offer field, CORS, and discovery files. That specificity makes it unmistakable against neighbors like url_safety_check or site_audit, which an agent can rule out without opening a schema.

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

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

Establishes the use case concretely ('the way buyer agents see it') and routes the agent to get_example for a free sample answer, plus gives an HTTP mirror. It does not explicitly say when to prefer site_audit or url_safety_check instead, so the comparison remains implicit.

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