call402 — x402 Agent Services

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

With no annotations at all, the description carries the safety burden and does so reasonably: it declares the tool read-only, tells the agent the data is cached, and warns that results carry a freshness status and source disclaimer. What is not disclosed is update cadence, whether listings include application links, or any rate limiting.

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, both information-dense: the first covers sources and scope, the second covers the return payload. The read-only constraint is front-loaded and there is no filler or restatement of the tool name.

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

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

No output schema exists, so the description must describe returns — and it does, listing cached jobs, freshness status, and a source disclaimer. Combined with the read-only declaration, that is nearly enough to call the tool correctly; only data refresh expectations and result shape (fields per listing) remain unspecified.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly avoids inventing filtering options (no user/workspace filters implied), which prevents the agent from attempting arguments that don't exist.

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 the concrete resource (aggregated job/bounty listings) and enumerates the four source providers, plus the secondary 'recent awarded bounties' payload. That is specific enough for an agent to know exactly what comes back. It loses a point only because no sibling tool overlaps, so the differentiation requirement is trivially met rather than deliberately addressed.

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

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

Usage is only implied: 'read-only aggregated listings' signals this is the place to go for job/bounty data, and the zero-parameter schema means there is no selection logic to explain. However, there is no explicit statement of when to call it, and no mention of when its data is unsuitable (e.g. cached results may be stale for time-sensitive queries).

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

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

With no annotations, the description carries the full burden. It helpfully discloses the method (eth_call pool discovery), the excluded segment (majors), the limitation that V3 depth is estimated, and that results are informational only, but it omits quote freshness, failure modes, and return format.

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

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

Four compact sentences, front-loaded with the core purpose, then method, exclusions, and caveat. There is no redundant filler, and each sentence adds relevant context.

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 cross-chain quote tool with no output schema and no annotations, the description gives a useful operational overview and limitations. It remains incomplete about how to supply the token parameter and what the returned quote looks like, which an agent needs in order 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 0%, so the description must explain the parameters. It names the three supported chains, which partially reinforces the chain enum, but does not explain the token parameter's expected format (e.g., contract address) or any additional 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 specifies the resource and scope precisely: quotes for long-tail EVM tokens from public DEX pools on three named chains, with majors excluded. It is easy to distinguish from sibling utility tools, though it never states a direct action verb or names an alternative tool.

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

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

It implies usage for long-tail tokens and explicitly excludes majors, and it labels the tool 'Informational only.' However, it does not state when to prefer it over an alternative or describe prerequisites such as having a token address.

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

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

Without annotations, the description carries the full burden. It discloses that data is 'live' and 'assembled from public protocol endpoints on our servers', implying a read-only lookup from public sources, but it omits details like rate limits, error behavior, or whether any authentication is needed.

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 efficiently front-load the purpose and then list use cases. The first sentence is dense but still readable, and no sentence is wasted.

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

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

For a lookup tool with no output schema and no annotations, the description adequately conveys what data will be returned (DNS records and RDAP fields). It lacks error-handling or response-format details, but those are secondary for a straightforward read operation.

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

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

With one parameter and 0% schema description coverage, the description only implies the input is a domain through the term 'domain' but gives no format guidance (e.g., whether to include protocol, subdomains, or an example). It barely compensates for the schema gap.

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 ('lookup') and resource ('domain') and lists exactly what is returned (DNS record types and RDAP fields). It distinguishes itself from most siblings by focusing on domain DNS/registration data, though it does not explicitly contrast with ssl-check or email-verify.

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 provides clear use-case contexts ('domain due diligence, phishing-site checks, counterparty infrastructure review and integration pre-checks') but does not specify when to avoid it or name alternative tools for overlapping tasks.

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

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

With no annotations, the description carries the full burden and does well: it discloses the verdict taxonomy, that MX hosts are returned, and the important caveat that catch-all domains may accept non-existent addresses. It omits operational traits like latency of the live MX lookup, rate limits, and whether the lookup is cached.

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, front-loaded with the core purpose, then the check list, then the returned verdicts, ending with the key limitation. No filler and 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 single-parameter, no-annotation tool with no output schema, the description covers purpose, the check pipeline, the return shape (verdict values plus MX hosts), and the catch-all caveat — everything an agent needs to call it and interpret results 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 0% and there is a single required 'email' parameter. The description makes clear an email address is being validated but adds no format or normalization guidance (e.g., whether it should be trimmed/lowercased). The parameter is largely self-evident, so this sits at the baseline.

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

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

States a specific verb+resource ('Email address validation') and enumerates the exact checks performed: syntax check, disposable/temporary-domain detection, and live MX-record lookup. An agent can immediately tell this apart from the unrelated sibling tools (fx-rates, weather, web-search), since none of them touch email validation.

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 contexts ('signup screening, lead cleanup and form verification') and a meaningful boundary ('Does not probe individual mailboxes'). There are no siblings that overlap, so no alternative-tool routing is needed, but it also states no exclusions for when not to use it.

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

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

No annotations are provided, so the description carries the full burden, and it delivers real operational context: data is served from a '30-minute cache' (staleness/latency expectation) and is free for commercial use with attribution (licensing constraint the agent may need to surface). It does not cover failure modes or rate limits, so it is not exhaustive.

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

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

Two sentences, front-loaded with what is returned before the use cases and provenance details. Dense and largely waste-free, though the promotional framing ('The most-cited single market-sentiment gauge') is persuasion rather than instruction.

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

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

With no output schema and no annotations, the description has to describe the response itself, and it does — value range, the five classification labels, and optional history. It is sufficient for correct invocation; only the `limit` semantics and error/timeout behavior are left unstated.

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

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

Schema description coverage is 0% and the single `limit` integer is undocumented in the schema. The phrase 'optional daily history' implies limit controls how many days of history are returned, which adds real meaning, but it never states units, default, or range, so the mapping remains inferred rather than specified.

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

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

Names a specific resource and provider ('Crypto Fear & Greed Index by alternative.me') and enumerates exactly what it returns: a 0-100 value, a named classification band, and optional daily history. This is unmistakably distinct from the sibling utilities (domain-lookup, email-verify, fx-rates, etc.), so an agent can select it without inspecting 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 concrete usage contexts — 'position sizing, risk checks and regime detection before trading' — which tells the agent when this signal is relevant. It stops short of explicit exclusions or naming an alternative tool, but the siblings are unrelated utilities so no routing conflict exists to resolve.

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

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

With no annotations, the description must carry the full behavioral burden; it does disclose the data source (ECB daily reference rates), refresh cadence (business day), and licensing (free, attribution required). It does not state what happens for an unsupported symbol, whether the call is read-only (implied by 'reference data'), how defaults are applied, or anything about rate limits — meaningful gaps for a zero-annotation 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 core capability and structured as what-it-is then how-to-call. Slightly padded by marketing phrasing ('the same source banks and accounting tools cite', 'clean JSON') that adds little operational information.

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

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

No output schema and no annotations mean the description should fully specify behavior, yet defaults for base/amount, error behavior for invalid symbols, and the shape of the returned rate object are all absent. What it does cover (source, cadence, licensing) is accurate but insufficient for a 3-parameter data 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 0%, so the description must document all three parameters, but it only gestures at 'base' and 'symbols' via the conversion example. The 'amount' parameter is never mentioned, and neither the default base currency nor the default amount (presumably 1) is stated, leaving the agent to guess the semantics of a conversion call.

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 foreign-exchange reference rates from the ECB — and the conversion operation ('pass base and symbols, get mid-market reference rates'). This is unambiguous and clearly distinct from any sibling tool (hashing, QR codes, timestamps, etc.).

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 a clear usage pattern ('convert between 30+ currencies with a single call: pass base and symbols') and pins the data currency ('updated every business day'). It stops short of explicit when-not-to-use guidance or naming alternatives for real-time tick data versus daily reference rates.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that computation is local with no upstream call (relevant for hashing sensitive input), but omits return format, determinism, error behavior, and how the `text` parameter is treated by the uuid op, leaving significant behavior undisclosed.

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

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

A single tight sentence that front-loads the core capability list and closes with the no-upstream caveat. No filler or repetition.

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

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

For a four-operation utility with 0% parameter documentation and no output schema, the description is incomplete: it never resolves the SHA-256 vs SHA-512 choice (unrepresentable in the schema), never explains `text` semantics per op, and says nothing about the shape of results.

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 0%, so the description must compensate. It explains the op values implicitly by naming the operations, but never documents the `text` parameter (required for hash/base64, presumably ignored for uuid) nor how an agent selects SHA-256 vs SHA-512, since no algorithm parameter exists in the schema.

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

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

The description gives a specific verb+resource ('Run local cryptographic utilities') and enumerates the exact capabilities (SHA-256/SHA-512, Base64 encode/decode, UUID v4), so an agent knows precisely what it does. No sibling (domain-lookup, fx-rates, etc.) competes with it, so explicit differentiation isn't needed, but the description also doesn't reference its siblings at all.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives. The only contextual hint is 'No upstream service is called,' which implies suitability for offline/local cases but never states it as a usage condition.

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

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

With no annotations, the description carries the full burden. It discloses the fixed model, output format (URL), latency (seconds), lack of fal.ai account/API key requirement, and per-call USDC payment via x402, which is strong behavioral context for a simple generator. It omits failure modes, rate limits, and prompt constraints.

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

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

The description is three tight sentences with the core purpose front-loaded, then model and pricing details. Every sentence contributes useful information without filler.

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

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

For a one-parameter tool with no annotations or output schema, it covers purpose, output format, cost, and payment model. The main gap is lack of prompt guidance, but the essentials for calling the tool are present.

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 0% for the sole 'prompt' parameter, and the description only says 'send a prompt.' It does not explain prompt format, length, recommended style, or any constraints, so it adds almost nothing beyond the schema's field name and type.

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: 'Text-to-image generation' that returns 'a generated image URL.' It clearly differentiates itself from all siblings (search, weather, token tools), so an agent can identify it 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?

It lists concrete use cases: thumbnails, illustrations, mockups, and visual assets inside agent workflows. No explicit when-not or alternative tool is named, but there is no competing image-generation sibling.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: execution is entirely local ('no upstream request'), and the supported language set is bounded to ten languages. It still omits input-size limits, behavior for unsupported or mixed-language input, and confidence thresholds.

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

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

Two tight sentences with no filler; the core action and the return payload come first, with the language list and local-execution note following.

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, but the description compensates by naming the returned fields (code, name, confidence, alternatives). What remains thin is input constraints — how much text to send and what happens with unsupported input.

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 0% and the single parameter has no schema description, so the description must compensate. It only implicitly identifies 'text' as the content to analyze, adding nothing about length limits, encoding, or format.

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

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

The description gives a specific verb and resource ('Detect the most likely language of text') and enumerates the returned fields (ISO 639-1 code, name, confidence, alternatives). No sibling tool does language detection, so it is trivially distinguishable from the listed 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?

Usage is only implied: the agent can infer you call this with a block of text to identify its language. There are no explicit when-to-use/when-not conditions and no alternatives named, though the sibling set contains no competing detector to route to.

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 useful work: it discloses local parsing via libphonenumber metadata, names the data source, and explicitly limits the result to format/number-plan validity. It leaves minor gaps around authentication, rate limits, and whether the operation is strictly read-only, but the core behavioral scope is clear.

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

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

Three tight sentences with no waste, and the core scope and limitation are front-loaded before the data-source note. Every sentence contributes to correct tool selection or interpretation.

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

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

For a simple two-parameter lookup with no output schema or annotations, the description adequately explains what is returned (format and number-plan validity) and what is not queried. The main missing piece is country-parameter semantics, which prevents a perfect score.

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 0%, so the description must explain the two parameters, but it only implies the 'number' parameter. The 'country' parameter is never explained, including whether it is a default region for parsing or required in some cases, leaving a meaningful gap for a low-coverage schema.

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

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

States a specific verb and resource: parse a phone number locally against the numbering plan. It also distinguishes the scope from verification tools by limiting results to format and number-plan validity, so an agent can tell it apart from siblings like email-verify or domain-lookup.

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

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

Clearly says the tool checks format and number-plan validity only, and explicitly excludes current network assignment and subscriber status. That gives a strong when-not signal, though it does not name any alternative tool for those excluded cases.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that rendering happens on the provider's servers and which library is used, plus the two output encodings, but says nothing about text length limits, rate limits, failure modes, or whether the PNG is a raw base64 string or a data URI.

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

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

Two tight sentences with the core action front-loaded and the audience/use case second. Both sentences earn their place, though the parenthetical library attribution is marginally promotional rather than operational.

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

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

No output schema exists, so the description reasonably covers the return shape (SVG markup or base64 PNG). However, with 3 parameters at 0% schema coverage and no annotations, the omission of 'size' semantics and any limits leaves an agent guessing on part of the call.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the 'text' parameter (any text, URL or payment address) and gives meaning to the 'format' enum (svg -> markup, png -> base64), but the 'size' parameter is never mentioned and no units or ranges are given.

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

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

States a specific verb and resource ('Generate a QR code image') and enumerates the accepted input kinds (text, URL, payment address). The sibling set is entirely unrelated utility tools, so no sibling disambiguation is needed; an agent knows exactly what this does.

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 explicit context for when to reach for it: agents that need scannable payment requests, links, addresses or tickets but cannot render images themselves. There is no statement of when not to use it and no named alternative, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden, and it does disclose a lot: the 5-minute cadence, v3 with a v4 cross-check, USD liquidity, derived fields only (the raw reference quote is excluded), and coverage from 2026-10-23 that includes market-closed hours. It says nothing about rate limits, payload size at longer windows, or error behavior for an unknown symbol, which are the remaining behavioral gaps for a read-only series 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 dense and front-loaded: what the series is, then sampling and vendor details, then coverage window and audience. Every sentence adds information, with only mild redundancy in restating that coverage includes closed hours and in the final audience clause.

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, no-annotation, no-output-schema tool, the description covers what is returned, how it is sampled, and how far back it reaches. The main gaps are the default for hours and any note on how long a 720-hour response is.

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 0%, so the description has to compensate, and it partly does: 'for one symbol' makes clear that symbol is singular per call, and 'can reach back up to 720 hours' plus 'the window ends at the latest available sample' gives hours a unit, an upper bound, and an anchoring rule. What is missing is the default value for hours when it is omitted.

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

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

The description states a specific verb-and-resource: a time series of stock-token spreads for one symbol on chainId 4663, with concrete content (5-minute samples of pool price, liquidity in USD, spread vs. reference quote). It does not explicitly name the sibling rh-stock-spreads (presumably the current-snapshot version), so the difference from that near-twin is left implicit.

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 scopes usage to 'research and market-structure analysis of tokenized stocks,' which is context but not a when-to-use rule. There is no explicit guidance such as 'use rh-stock-spreads for the latest snapshot' or a statement of when not to use this tool, so an agent must infer the choice between the two spread tools.

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

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

With no annotations, the description carries the full burden and does so: it discloses that only derived fields are returned, that the reference quote is excluded, that sampling runs every 5 minutes including while US markets are closed, and that each response carries a timestamp, data age, and stale flag. It also flags the 24-hour trailing statistics, so the agent knows both the freshness semantics and the payload shape.

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 resource and coverage before moving to caveats, and every clause carries information (coverage list, derived-only caveat, staleness fields, 24h stats, non-execution disclaimer). It is dense but slightly long, with the symbol enumeration taking substantial space for low decisional value.

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

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

There is no output schema, yet the description compensates by enumerating the returned fields, the staleness metadata, and the per-symbol 24-hour statistics. For a zero-parameter read tool, an agent has everything needed to call it and interpret the result without further documentation.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning for the description to add. The schema is empty and fully covered, leaving nothing ambiguous.

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 (Robinhood Chain stock-token spread snapshot), the chainId, the exact 12 symbols covered, and the three data elements returned (v3 pool price, v4 cross-check, USD liquidity, spread vs reference). This is far more than a restatement of the name and lets an agent decide relevance 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?

It supplies an explicit usage boundary: 'For monitoring and research, not an execution feed,' which tells the agent not to rely on it for trade execution. It does not, however, mention the sibling rh-stock-spread-history or state when to prefer the historical variant over this snapshot, leaving that distinction to inference from 'Latest'/'snapshot'.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the non-obvious access model: no account/API key/subscription, paid per call in USDC via x402. It also describes the return payload (titles, URLs, descriptions, result age). It stops short of covering rate limits, error behavior, or result caps, which for a paid per-call tool would be useful.

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

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

Front-loads the core action and keeps to three compact clauses with no filler paragraphs. A few phrases ("ready to cite, summarize or read further", "powered by Brave Search") lean promotional rather than informational, but the text is efficiently sized overall.

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

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

With no output schema and no annotations, the description does the heavy lifting well: it describes return fields, usage contexts, and the payment/access model. The one notable hole is the undocumented num_results parameter, but for a simple two-param search tool the coverage is otherwise strong.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the semantics of "query" as a natural-language string, but says nothing about "num_results" — its range, default, or valid bounds. Half the parameters remain undocumented in both schema and description.

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 (search) and resource (live web), and pins down the source as "Brave's independent web index," which meaningfully separates it from the sibling search-tavily. It does not name the sibling tools directly, so the differentiation is implicit rather than explicit.

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

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

Gives concrete usage contexts ("research, fact-checking, news and docs lookups, price and competitor checks inside agent workflows"), which is clear when-to-use guidance. It offers no when-not-to-use conditions or comparison against the other search siblings (search-tavily, web-search, web-answer), leaving the routing decision partly to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the fixed basic search depth, the one-credit-per-call cost, and the pay-per-call USDC/x402 model requiring no API key or subscription. It omits rate limits, failure behavior, and any latency or quota caveats.

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 in the first clause and the pricing/auth constraints follow in a logical order. The 'built for research agents, fact-checking and RAG pipelines inside agent workflows' clause is somewhat padded and restates the earlier agent framing.

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 or annotations, and the description usefully covers return fields, auth and cost, which partially compensates. But the two input parameters remain undocumented, leaving a real gap for a tool the agent must call with correct arguments.

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 0% for two parameters, so the description must compensate and does not: 'query' is only obliquely implied by 'send a natural-language query' and 'num_results' is never mentioned. Nothing tells the agent the accepted range or defaults for the result count parameter.

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

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

States a specific verb+resource (live web search powered by Tavily) and enumerates the return shape (titles, URLs, content snippets, relevance scores), so the agent knows exactly what it gets. It does not, however, distinguish itself from close siblings like search-brave or web-search, which an agent must choose between.

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 names intended use cases (research agents, fact-checking, RAG pipelines) which implies when the tool fits, but never says when to prefer it over search-brave or web-search, nor when it is the wrong choice. Usage is implied rather than guided.

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

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

With no annotations, the description carries the full burden. It does add useful disclosure: the data source is public-domain EDGAR and a declared User-Agent is used. However it omits error behavior for unknown tickers/names, SEC rate-limit considerations, and which fiscal period is chosen when multiple exist.

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

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

Two sentences, front-loaded with what is returned from where, then how to target it. Every clause adds information; 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 simple lookup with no annotations, no output schema, and 0% parameter coverage, the description covers purpose, inputs, and return content. It still leaves gaps on input formats, units/currency of the figures, and failure behavior, which the structured fields do not cover.

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 0% and the three properties have no descriptions, so the description must compensate. It does map the three parameters (ticker, CIK, name) to their purpose, but gives no format guidance (e.g. uppercase ticker, numeric CIK, name matching rules).

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

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

The description names a specific verb ('Summarize') and a precise resource ('SEC-reported Revenue, NetIncomeLoss and Assets from official EDGAR companyfacts'), plus the lookup keys. It is unambiguous and cannot be confused with any sibling tool (all unrelated utilities).

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 how to target a company ('Look up by ticker, CIK or company name'), which is clear invocation context. It does not state edge cases such as what happens with an unmatched or ambiguous name, and there are no competing alternatives to route against, 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?

With no annotations, the description carries the burden, and it discloses meaningful behavior: the result comes from a direct TLS handshake from the provider's own servers, and it is scoped to public hosts only. It omits failure handling (expired/self-signed certs, timeouts) and rate limits, so it is good but not complete.

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 that are front-loaded with the core purpose and output list, with no filler. The dense field enumeration is justified because there is no output schema, though it makes the first sentence long.

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

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

With no output schema and no annotations, the description steps in by enumerating the returned fields (issuer, subject, SAN, validity, days-to-expiry, fingerprint, chain verification) and the data source, which is enough to call it correctly. Error and timeout behavior are the remaining gaps.

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 documents the single 'host' parameter at 0% coverage, so the description must compensate. It implies the parameter is a hostname on the public internet, but gives no format guidance (host vs. URL vs. IP, port, SNI), leaving the only input under-specified.

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 ('TLS/SSL certificate check for any public host') and enumerates exactly what the check produces, so an agent knows precisely what it does and gets back. It is clearly distinguishable from siblings like domain-lookup, email-verify and fx-rates.

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

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

Provides concrete usage contexts ('uptime and security monitoring agents, vendor endpoint checks and integration pre-flight'), which gives a clear when-to-use signal. It does not name an alternative or state exclusions (e.g. certificates on private hosts), so it falls 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?

With no annotations, the description carries the full burden and does add real behavioral context: server-side Mozilla Readability processing, boilerplate/nav/ad stripping, first-party provenance with no third-party reselling, and an implicit scope limit to public pages. What it omits is failure behavior — paywalled, JS-rendered, or authenticated pages, plus any rate limits or error modes.

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, front-loaded with the core action and return payload before the use cases. The closing line about not reselling a third-party reader service is slightly promotional, but it does carry provenance information, so it roughly 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?

With no output schema and no annotations, the description steps in to describe the return shape (title, excerpt, body text), which is exactly what is missing elsewhere. What remains uncovered is error/limit behavior for non-public or dynamic pages, a minor gap for a single-parameter extraction 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 0% and the single 'url' parameter has no format, validation, or example in the schema. The description partially compensates by saying 'send a URL' for 'any public web page', which conveys the accepted value domain, but adds no syntax or edge-case guidance.

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

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

Specific verb ('extract') plus resource ('readable main content of any public web page') and an explicit statement of what comes back (page title, excerpt, body text). The 'as clean text' framing also implicitly separates it from the sibling text-to-structure tool, which produces structured output.

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

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

It lists target scenarios (RAG ingestion, summarization, research, page monitoring), which implies when the tool is appropriate, but never states when NOT to use it or names an alternative. The nearest sibling, text-to-structure, is never referenced, so the agent must infer the routing itself.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses determinism ('same input, same output'), the latency profile ('in milliseconds'), and that no LLM call is involved — all traits an agent cannot infer from the empty schema. It does not cover failure modes, input size limits, or behavior when no entities match, which keeps it out of 5 territory.

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 verb-resource-output framing, then the positioning, then the supported entity list. The enumeration of extraction types is long but directly aids tool selection, so it earns its place; a slight trim would make it 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, so the description must describe returns — and it does ('strict, machine-readable JSON', 'exactly the fields you need'). Combined with the stated determinism and supported entity types, an agent has enough to call it correctly, though input limits and empty-match behavior remain unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate for three bare parameters. It explains the intent of the two optional ones ('pass fields or a JSON schema to receive exactly the fields you need') and implies 'text' is the source input, but never states the expected shape of 'fields' (array of strings) or 'schema' (a JSON schema object), leaving the schema's type-only definitions to do that 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 concrete verb and resource ('Turn unstructured text into strict, machine-readable JSON') plus the exact extraction categories it supports. The positioning as 'a deterministic, reproducible alternative to an LLM extraction call' makes it unmistakable against siblings like web-search or token-risk-summary, which do entirely different things.

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

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

Gives clear context for when to reach for it: agent pipelines needing reproducible structured output from invoices, emails, messages, logs or documents, and the 'pass fields or a JSON schema' instruction tells the agent how to steer results. It stops short of explicit when-not-to-use guidance or naming an alternative tool to use 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?

No annotations exist, so the description carries the full behavioral burden. It usefully discloses accepted input formats and that output covers two timezones, but it omits what happens if both date and timestamp are supplied, how a bare number is disambiguated between seconds and milliseconds, and how invalid input is handled.

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 core conversion and accepted formats front-loaded and the empty-object edge case appended. 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?

For a simple pure-conversion tool with no output schema, the description adequately covers inputs and outputs (UTC and Asia/Shanghai). The only meaningful gap is the unstated precedence/interaction between the two optional parameters and error behavior on malformed input.

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 0%, so the description must compensate; it does partially by mapping 'date' to ISO dates and 'timestamp' to Unix seconds/milliseconds. However it does not resolve the seconds-vs-milliseconds ambiguity for a raw number, nor state precedence when both optional parameters are present.

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 (Convert) and the exact resource/transform (Unix seconds, Unix milliseconds, ISO date → UTC and Asia/Shanghai timestamps), including the input formats and output timezones. No sibling tool overlaps with timestamp conversion, so an agent can route to it unambiguously.

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 explains the zero-argument case ('An empty object returns the current time'), which is genuine usage guidance for one path, but it never says when to prefer this tool or how to choose between the date and timestamp inputs. With no sibling alternative to compare against, usage 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?

With no annotations at all, the description carries the full burden and does reasonably well: it discloses that sources are fail-soft and enumerated in the response, which warns the agent that results may be partial and which source failed. It does not cover latency, rate limits, or error behavior, but the fail-soft disclosure and source attribution are meaningful beyond-schema context.

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

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

A single dense sentence with zero filler; the core purpose is front-loaded and the sources/chain defaults follow logically. It is slightly run-on and could be split for scanability, but no clause is wasted.

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

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

Absent an output schema, the description still conveys the return shape (risk flags, a four-grade risk_level, listed sources), which is what an agent needs to interpret results. It leaves the actual grade labels and the meaning of individual flags unspecified, a minor but real gap for a tool whose whole value is the verdict.

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 0% and the schema lists bare string types with no descriptions, so the description must compensate and largely does: chain defaults to base and accepts chainId 8453, 1, or 56, and address is constrained to one contract address. It stops short of format details (checksum/casing, whether 'base' is case-sensitive), which keeps it below 5.

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 (ERC-20 token safety check for one contract address) and enumerates exactly what is checked: honeypot/tax simulation, liquidity and pair age, plus on-chain reads distilled into risk flags and a four-grade risk_level. It is clearly distinct from siblings like wallet-lookup, dex-quote, or wallet-lookup-pro, which address different objects.

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 scopes usage to a single contract address on Base, Ethereum, or BSC, which implicitly tells the agent when this tool applies. However, it never explicitly says when to prefer it over adjacent tools (e.g., wallet-lookup-pro for address reputation, dex-quote for pricing) and gives no exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the data source (direct Base chain read via public RPC, self-hosted, no third-party API), the discovery-window default of ~28 hours, and the key limitation that uncovered tokens without recent transfers are omitted. It stops short of stating rate limits, failure modes, or address-format validation.

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, front-loaded with the core purpose before the caveats, with no filler. The coverage sentence is dense but each clause carries real information about the returned data.

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

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

No output schema and no annotations exist, so the description is the only source of truth, and it covers data provenance, scope (513 curated tokens), the coverage caveat, and the absence of USD values. What is missing is the response shape beyond the coverage field, error behavior, and address validation, which are minor for a read-only lookup.

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 0%, so the description must compensate for two bare parameters. It partially does: 'discovery window (default about 28 hours)' explains the optional window parameter's purpose and default (though not its unit or maximum), and the address is implicitly a Base-format address. That is meaningful but incomplete compensation for the coverage gap.

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

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

The description gives a specific verb and resource (look up a Base wallet address) and enumerates exactly what is returned: native ETH plus balances for a curated 513-token list. It does not mention the sibling wallet-lookup-pro, so an agent cannot tell from this text alone which of the two to pick, which keeps it below a 5.

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

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

Usage is implied rather than stated: 'Balances only; no USD valuation' and 'Base chain state' signal when this tool is and isn't appropriate, but there are no explicit when-to-use instructions and no routing to wallet-lookup-pro or token-safety. An agent must infer the boundary conditions.

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

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

With no annotations supplied, the description carries the full burden and does it well: it names the data sources (public RPC, DexScreener prices), discloses that USD values are estimates and may be null for illiquid tokens, and explains partial-failure semantics — per-chain errors are reported per chain rather than failing the whole call. It does not mention rate limits, address validation, or latency, which keeps it from a 5.

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

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

Four dense sentences, front-loaded with the core verb and scope, then data sources, then default behavior, then caveats. Nearly every clause earns its place; the paragraph is a long run-on but contains no filler or repetition.

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

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

For a two-parameter read tool with no output schema, the description covers what is returned (native plus curated token balances with USD estimates), where the data comes from, and how partial failures surface. The remaining gap is address input format and any limits on how many tokens are returned, which an agent could still get wrong.

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 0%, so the description must compensate. It does explain 'chains' (optional subset, defaults to all three) but says nothing about the required 'address' parameter — expected format, checksum casing, or whether ENS names are accepted — leaving the most important input under-specified.

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 ('wallet portfolio lookup') plus exact scope: native coin and curated token balances with USD valuation for one address across Base, Ethereum and BSC. The multi-chain framing implicitly separates it from the sibling 'wallet-lookup', but it never names that sibling or states the contrast explicitly, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer this is the tool for a read-only portfolio snapshot, and the 'chains' default is explained. There is no explicit when-to-use versus alternatives (e.g. 'wallet-lookup' for a single chain) and no exclusions, such as not for transaction history or safety checks (that's 'token-safety').

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

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

With no annotations, the description carries the full burden and does disclose important behavior: synthesized answer with citations, no result list, and the unusual payment model (no account/API key, pay per call in USDC via x402). It omits latency, rate limits, and failure modes, but the auth/payment disclosure is materially useful.

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

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

Front-loaded with the core outcome (question in, synthesized answer with citations out), followed by usage context and the pricing model. Two sentences, each earning its place, though the x402 detail is dense.

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

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

No output schema exists, and the description compensates by describing the return shape ('the answer plus its sources'). For a single-param tool with no annotations, the purpose, return, and payment model are all covered; missing only operational caveats like rate limits or failure behavior.

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?

One parameter with 0% schema description coverage. The description's phrase 'ask a question in natural language' does imply the query is free-form NL text, which adds some value. Beyond that it offers no length, formatting, or content guidance for the query.

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: 'ask a question and get a direct synthesized answer with citations.' It also implicitly distinguishes itself from siblings web-search/web-extract by stating there is 'no result list to sift through.' An agent can tell this apart from web-search without reading either schema.

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

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

Explicit when-to-use: fact lookups, research questions, market/competitor questions in agent workflows needing an answer rather than links. It never names web-search as the alternative for link needs, though the 'answer, not links' framing implies it. Clear context, no explicit exclusion of a named sibling.

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

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

With no annotations, the description carries the full burden and does disclose non-obvious traits: no account/API key needed, per-call payment in USDC via x402, and that navigation/boilerplate are stripped. It omits failure behavior (paywalled, JS-rendered or blocked pages) and how limits/truncation are handled.

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 action and output format are front-loaded, followed by a punchy 'Send a URL, get the text.' and the payment note. Some promotional padding ('any public web page', the content-type list) adds length without much decision value, but nothing is badly buried.

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

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

There is no output schema, but the description states the return format (clean LLM-ready markdown with boilerplate stripped) and the payment model, which covers most of what an agent needs. The remaining gap is undocumented `max_chars` behavior and error/limit handling.

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 0%, so the description must compensate and does not. `url` is self-evident, but `max_chars` is never explained in either place, leaving its truncation semantics (units, default, behavior on overflow) undefined.

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

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

The description gives a specific verb and resource: fetch a public web page and extract readable content as markdown, explicitly covering articles, docs, blogs, product pages and PDFs. This is clearly distinguishable from siblings like web-search (query-based) and web-answer (returns an answer, not raw content).

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 contexts in which this tool belongs: RAG ingestion, summarization, research and page monitoring inside agent workflows. However, it never names alternatives or states when NOT to use it (e.g. when to prefer web-search or web-answer), so routing guidance stops short of explicit exclusions.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the provider (Exa), that results are ranked, the response fields, and crucially the auth/payment model ('No Exa account, API key or subscription needed: pay per call in USDC via x402'). It stops short of rate limits, failure modes, or result-capping behavior.

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

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

Front-loaded with the core capability, then return contents, then use cases, then the payment caveat. Dense but nearly every clause adds information; the marketing-flavored positioning phrase ('for AI agents, powered by Exa') is the only near-waste.

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

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

For a two-parameter search tool with no output schema and no annotations, the description covers purpose, output shape, usage contexts, and the unusual payment requirement. The remaining gap is the undocumented num_results parameter and any error/pagination behavior, which an agent could plausibly need.

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 0% and annotations supply nothing, so the description must compensate. It clarifies that 'query' is natural-language and free-form, which adds real meaning, but it never mentions 'num_results' at all — no default, no maximum, no range — leaving half the parameters undocumented anywhere.

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 ('Live web search ... send a natural-language query and get ranked results') and even enumerates the return payload (titles, URLs, publish dates, text highlights). An agent knows exactly what this does without opening the schema, and the sibling tools (text-to-structure, token-risk-summary, wallet-activity-summary) are in unrelated domains, so no differentiation burden applies.

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 when-to-use contexts: 'research, fact-checking, news and docs lookups, price and competitor checks inside agent workflows.' That is clear positive guidance, though it names no exclusion or alternative tool for cases where a web search is the wrong choice.

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