x402 Tools

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

No annotations provided, so the description carries the full burden. It discloses cost ($0.005 per call), which is valuable, but doesn't mention rate limits, data freshness, or what happens on failure. Cost disclosure is a strong addition, but more behavioral context is needed for a tool with no 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?

Two sentences, front-loaded with cost and capabilities, followed by use case. No wasted words.

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

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

Given no output schema, the description enumerates the data returned (registrar, dates, DNS, CT), which is good. However, it doesn't describe the response format or structure. Cost is included, which is helpful. Reasonably complete but could specify output format.

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 there is only 1 parameter. The example 'example.com' in the schema description adds a bit, but the description itself adds no new parameter semantics beyond what the schema provides. Baseline 4 for 0 parameters is not applicable; here, with 1 parameter fully documented, 4 is appropriate for no extra 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+resource ('Domain due-diligence bundle') and enumerates exactly what it retrieves: RDAP registrar, dates, DNS records, and CT history. This is clearly distinguishable from siblings like free_url_check or web_brief.

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

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

Explicitly states the use case: 'Use to vet a domain before trusting or linking to it.' This gives clear context, though it doesn't name an alternative or 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?

With no annotations, the description carries the load and does well: it discloses cost ($0.002 per call), that no API key is required, the upstream source, and that it returns rates plus a last-update timestamp. It omits rate limits and error behavior, but the cost and auth disclosures are meaningful context an agent would not otherwise have.

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, front-loaded with the cost signal, then source, then params, then return shape. No filler; 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?

There is no output schema, and the description compensates by naming what is returned (rates + last-update timestamp). For a 2-param read tool this is nearly complete; only error/rate-limit behavior is 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 coverage is 100%, so both parameters are already documented, and the description largely repeats that (defaults, comma list, ISO code). It adds only minor meaning (ISO code framing), 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 ('Live fiat exchange rates'), names the data source (open.er-api.com), and scopes it (~200 currencies, no key). This clearly separates it from siblings like stock_quote or sec_edgar_search without needing to open 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 is implied by the purpose ('fiat exchange rates') but there is no explicit when-to-use, when-not-to-use, or named alternative among the siblings. An agent can infer conversion use cases, but nothing routes it away from the tool when inappropriate.

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 cost ($0.02 per call), authentication (no key), and a rate limit, plus a partial sketch of returned fields. It stops short of pagination limits or error behavior, but the cost/auth/rate context is genuinely 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?

A single tight block that front-loads the two facts an agent most needs before calling (price and source), then compresses params and returns. Slight redundancy with the schema's own parameter descriptions is the only 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 no-annotation, no-output-schema read tool with three optional params, the description covers cost, auth, rate limiting, param semantics and the shape of results. Missing only secondary details like result caps or pagination 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?

Schema description coverage is 100%, so all three parameters are already documented in the schema; the description repeats them with defaults and adds only the 'free-text filter' nuance for reason. Baseline 3 is correct when the schema does the heavy lifting.

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

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

Names a specific resource (FDA recall enforcement reports) plus the exact source (open.fda.gov), which is enough to distinguish it from every sibling such as sec_edgar_search or usgs_earthquakes 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?

The description supplies the dataset, the food|drug|device selector and defaults, which implies when the tool applies, but never states when to prefer it over a sibling or when not to use it. No exclusions or alternative routing are given.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose the return shape, redirect-following behavior, and the free/paid cost model relative to web_fetch. It stops short of stating timeouts, rate limits, or whether private/non-public URLs are rejected, which matters for a network-egress tool.

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

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

Three short sentences, front-loaded with the purpose and return values before the alternative. The doubled 'FREE — FREE:' prefix is redundant noise that costs a little precision.

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 compensates by enumerating the returned fields, and the single-parameter surface is fully documented in the schema. For a one-arg read-only probe this is close to sufficient, with only failure/edge-case behavior left implicit.

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

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

Schema coverage is 100% for the single 'url' parameter, so the baseline is 3. The description's 'public URL' wording adds a mild constraint the schema lacks (schema only notes protocol is optional), but no format or syntax 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 ('check whether a public URL is reachable') and enumerates the exact payload returned (HTTP status, final URL after redirects, content type, page title). That enumeration distinguishes it cleanly from web_fetch and web_brief among the siblings.

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

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

It names the alternative explicitly — 'Use web_fetch (paid) for full text and links' — and gives the condition that selects it, so an agent can route between a cheap reachability probe and a full-content fetch without guessing. The 'FREE' marker adds a cost dimension to the decision.

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 discloses the cost per call and the returned fields, but omits authentication requirements, rate limits, error behavior, and whether private repositories are supported. These gaps leave meaningful uncertainty for an agent deciding whether to invoke it.

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: the first front-loads cost and return fields, the second states the use case. Every clause earns its place with no redundancy or filler.

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

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

The tool is simple, schema coverage is complete, and the description compensates for the absent output schema by listing the returned fields. It still lacks operational details like auth and rate limits, but for a read-only public-data lookup this is largely sufficient.

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

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

Schema coverage is 100% for the single 'repo' parameter, and the schema already documents that it accepts 'owner/name' or a URL. The description adds no further parameter detail, so the baseline score of 3 applies.

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

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

The description names a specific resource ('GitHub repo snapshot') and enumerates the exact fields returned, making the tool's purpose immediately clear. It does not differentiate itself from the sibling repo_diligence, which may offer overlapping or deeper analysis, so it falls 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?

It gives a clear use case: 'Use to triage a repo before contributing or depending on it.' This tells the agent when to reach for the tool. However, it offers no exclusions or alternatives (e.g., when to use repo_diligence instead), so it is not fully prescriptive.

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 cost ($0.002 per call), the auth profile (no API key, no signup), and the payload contents. It omits error behavior, rate limits, data freshness/caching, and units for wind speed and precipitation.

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 price and source, then the return contract, then the required params — a sensible order with almost no waste. The closing 'Params: lat, lon (required)' largely duplicates the schema and could be dropped.

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 annotations and no output schema, the description covers cost, auth, input contract, and return fields, which is nearly everything an agent needs. Missing units and error/timeout behavior are the only real 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?

Schema description coverage is 100% with both lat and lon documented, so the schema does the heavy lifting; the description merely restates that lat and lon are required. It adds no coordinate convention (WGS84, decimal degrees) or valid ranges 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?

States a specific resource and scope ('Current weather from Open-Meteo') and enumerates the returned fields (temperature, apparent temperature, humidity, wind speed, precipitation, WMO code). The 'current' qualifier implicitly separates it from forecast/historical variants, though no sibling is named for routing.

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 by 'Current weather' plus 'Given lat/lon', so an agent can infer it is the tool for current conditions at a coordinate. There is no explicit when-not-to-use, no alternative named, and no mention of forecast/historical coverage limits.

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

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

No annotations are provided, so the description carries the full burden. It discloses the per-call cost ($0.03), the exact read scope, and the recency bound (last 5 commits), which is real behavioral context beyond the schema. It stops short of stating explicitly that the operation is read-only or what happens on an invalid/private repo.

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

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

Two sentences with zero waste: the cost is front-loaded and the field inventory follows immediately, then the decision context. Every clause 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?

No output schema exists, so the description must explain return values itself, and it does so thoroughly (snapshot, commits, contributors, archived, security policy, release cadence, issue ratio). Combined with the usage rationale, an agent has everything needed to call and interpret it.

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

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

One parameter with 100% schema description coverage ('owner/name, URL also accepted'), so the schema already documents the single input. The description adds no syntax or format detail beyond what the schema provides; baseline 3 is appropriate.

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

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

States a specific verb and resource ('Deep GitHub repo due-diligence') and enumerates the exact data returned: base snapshot, last 5 commits, contributor count, archived flag, security policy, release cadence, issue ratio. An agent can distinguish this from the sibling github_repo 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?

Gives clear context for when to use it: to decide whether to depend on or contribute to a repo before trusting it. However, it does not name an alternative (e.g. github_repo or web_fetch) or state when not to use this paid tool, so the routing guidance is contextual but incomplete.

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 real work: it discloses cost ($0.02 per call), auth requirements (no key), the upstream host, and the return shape (date, company, CIK, accession number). It stops short of pagination or rate-limit behavior, so it is strong but 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?

Cost is front-loaded, the core capability follows, and the param recap is compressed into one line. Slightly redundant with the schema, but nothing is padded or 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 enumerates the returned fields, and with no annotations it covers the cost and auth profile an agent needs before calling. Only pagination and error behavior remain unaddressed for a simple three-param search.

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 all three parameters are already documented in the schema. The description's param recap (q required, forms comma list, limit default 10) largely restates the schema, adding only the comma-separated form example, which is already present as well. 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 ('SEC EDGAR full-text search', 'Find filings by term') and pins the exact backend (efts.sec.gov). No sibling tool touches SEC filings, so disambiguation is trivially satisfied.

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 by 'Find filings by term', but there is no explicit when-to-use, when-not-to-use, or routing to an alternative for company-level lookups. Given the sibling set is entirely unrelated domains, the gap is low-impact but still a gap.

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 behavioral traits: cost ($0.01 per call), no API key required, the upstream source (Tencent qt.gtimg.cn) and a Nasdaq fallback for US tickers. It omits rate limits, error/empty-symbol behavior, and latency characteristics, but the disclosed operational context is well above average.

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 essentially one dense, front-loaded block that packs cost, output fields, market coverage, batching, auth and data source into a few clauses with no filler. It is slightly run-on, but every clause 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 single-parameter tool with no annotations and no output schema, the description does the needed work: it enumerates returned fields (compensating for the missing output schema), covers auth, cost, symbol formats and data provenance. The only real gap is failure/edge-case behavior for invalid or empty symbols.

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

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

Schema coverage is 100% for the single parameter, so baseline is 3, but the description adds symbol-format guidance beyond the schema example — prefix conventions for A-shares (sh600000, sz000001), HK (hk00700) and US (usAAPL or plain AAPL) plus comma batching. Note the schema example uses a different style (600519.SS, 00700.HK), which is a minor inconsistency the description does not resolve.

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 ('Real-time stock quotes') and enumerates the returned fields, making it clearly distinguishable from siblings like exchange_rates or sec_edgar_search. An agent can identify the tool's function 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?

The description explains how to call it (comma-separated symbols) and what markets are covered, but never states when to prefer it over alternatives such as exchange_rates or when it would be inappropriate. Usage context is implied rather than explicit.

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

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

With no annotations provided, the description carries the burden and does well: it discloses the cost ($0.005 per call) and the read-only mechanism (eth_call), which tells the agent this is a non-mutating on-chain lookup. It omits edge behavior—what happens for an address that is not a valid ERC-20 (revert, null fields?)—which keeps it out of the 5 range.

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 compact clauses: cost and capability first, then the intended use. Zero filler, front-loaded with the distinguishing facts.

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 compensates by listing the four returned fields (name, symbol, decimals, total supply), so the agent knows the shape of the result. The remaining gap is failure/edge-case behavior, which is modest for a trivial one-address read.

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 'address' parameter, so the schema already documents format and chain. The description reinforces the Base/ERC-20 constraint but adds no syntax, casing, or checksum detail beyond it; baseline 3 for a fully covered schema is correct.

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 ('Base ERC-20') and enumerates exactly what is fetched: on-chain name, symbol, decimals and total supply. The mechanism ('via eth_call') and chain scope make it unmistakable and clearly distinct from the unrelated sibling tools (stock_quote, repo_diligence, 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?

'Use to sanity-check a Base token address before interacting with it' gives a concrete trigger context. It stops short of naming an alternative or stating exclusions (e.g. non-Base chains, non-ERC-20 contracts), but no sibling covers this domain so the absence is minor.

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 data source (USGS GeoJSON), that no API key is needed, and the per-call cost of $0.002. It stops short of stating rate limits, pagination behavior, or how fresh the feed is.

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?

Cost and source are front-loaded, followed by the payload and parameters, in a compact multi-clause form with no filler. The parameter restatement is somewhat duplicative of a schema that already documents every field with defaults.

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 no-auth, three-optional-param read tool with no output schema, the description supplies source, cost, auth posture, parameter defaults, and the shape of each returned event. Only freshness/rate-limit details are absent.

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 already 100%, so the baseline is 3, but the description's param list actively narrows the enum: it says 'period = hour|day|week' while the schema also permits 'month'. An agent relying on the prose alone would miss a valid option, which is worse than adding nothing.

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 ('Recent earthquakes from the USGS GeoJSON feed') plus the exact fields returned (magnitude, place, time, depth, coordinates). No sibling tool overlaps this domain, so the 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?

Usage is only implied by the parameter defaults (period, minmag, limit); there is no explicit statement of when to reach for this tool versus alternatives, nor any exclusions. For a simple single-purpose read tool with no comparable siblings, that is minimally adequate rather than strong.

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 reasonably well: it discloses the $0.02 per-call cost, the 1–3 URL input bound, and the structured/citable output format intended for other agents. It stops short of covering error behavior, rate limits, or partial-failure handling for individual URLs.

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, front-loaded with the cost signal, then the operation and output. Every clause carries 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?

No output schema exists, so the description must explain return values — and it does list the extracted fields (title, meta description, key sentences, outbound links) and the brief format. It is largely complete for a 2-parameter tool, though per-URL failure behavior is 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 coverage is 100%, so both parameters are already fully documented in the schema. The description reinforces the URL count and hints at the sentence-selection criteria, but adds no syntax or format detail beyond what the schema provides, 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?

The description names a specific operation (multi-source research brief from 1–3 URLs) and enumerates exactly what is extracted, so the agent knows what the tool produces. It does not explicitly name web_fetch as the raw-fetch alternative, so sibling differentiation is implied rather than stated.

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 'multi-source research brief' framing implies when the tool is appropriate, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative such as web_fetch. Usage is inferable but not spelled out.

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 supplied, so the description carries the full burden, and it does well: it discloses per-call cost ($0.005), the exact return shape, that scripts/styles are stripped, and that text is truncated. 'Public URL' implicitly rules out authenticated/private content. It still omits rate limits, auth requirements, and whether JS-rendered pages 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?

Two sentences: cost first, then the operation and payload, then a single routing hint. Every clause earns its place and nothing is repeated from the schema.

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 well by enumerating the returned fields including the top-20 link cap. It is nearly complete for a simple fetch tool; only edge behavior such as timeout/error handling and JS-rendering support is 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 100%, so both url and maxChars are already documented with defaults and protocol behavior. The description's mention of truncated cleaned text loosely ties to maxChars but adds no syntax or constraints beyond the schema, making 3 the correct 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 ('Fetch a public URL') and enumerates the return payload (status, final URL, title, cleaned text, top 20 links), which is unusually precise for a fetch tool. It does not differentiate itself from plausible siblings like web_brief or free_url_check, so it stops short of 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?

'Useful when an agent itself cannot reach the open web' gives one triggering condition, which is a real usage hint rather than none. However, it never says when to prefer this over web_brief (presumably the summarization sibling) or free_url_check, so the agent must infer the routing.

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