Agent Data Tools: Web and documents

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

Beyond the annotations it discloses that only public published files are read, nothing is signed in or submitted, and that every call is billed ($0.01 via x402 USDC or card key, first 25 free, failures free, repeats not free). That adds auth, cost and non-idempotency context the readOnly/openWorld hints alone don't convey.

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 front-loaded with the score, the checked artifacts and the returned data, then behavior and pricing. It runs long in a single block and could be split, but nearly 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?

With no output schema, the description still enumerates the return contents (found/missing per artifact with URLs, robots.txt crawler verdicts, fix list), plus cost and read-only behavior. An agent has everything needed to decide and invoke correctly.

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

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

Schema coverage is 100% and the schema already explains that a domain or any URL on it is accepted and that only the origin is checked. The description reinforces this with an example URL but adds no new semantics beyond the schema.

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

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

The description gives a concrete verb and object (score a website's AI-agent readiness 0-100) and enumerates exactly what is checked: llms.txt, sitemap, OpenAPI spec, MCP server card, A2A agent card and x402 discovery. That clearly separates it from adjacent siblings such as audit_website, seo_audit or pack_website_audit, though none of those siblings is named explicitly.

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

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

It states two concrete use cases ('audit your own site or vet a service before an agent relies on it') and supplies a worked call example with url=https://stripe.com. It stops short of stating when a sibling tool (e.g. seo_audit) would be the better choice.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, and the description reinforces the safety profile ('reads or computes only and changes nothing'). The genuinely additive context is the billing model — $0.01/call via x402 USDC or card key through /credits, failed calls free, repeats not free — which explains the non-idempotent flag and warns against retry loops; a 3 rather than higher because cost is the only behavioral trait it expands on.

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 what is audited and what is returned, then usage cases, then pricing and safety. It is a dense paragraph with no filler sentences, though the pricing/safety tail and the component list make it long enough that a sentence break would improve scanability.

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

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

There is no output schema, so the description carries the full burden of describing results, and it does: rule, impact, elements and fix link for accessibility, FCP/LCP/layout shift and page weight for speed, plus an overall score and top issues. Cost, payment path, failure policy and the read-only guarantee round out everything an agent needs to call it correctly.

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

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

With only one parameter at 100% schema coverage, the schema already documents 'Absolute http(s) URL of the page to audit'. The description adds a worked example (url=https://www.wikipedia.org/) and the constraint that only one URL per call is audited ('one URL', 'single load'), which is useful but marginal, so the high-coverage baseline of 3 applies.

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

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

The description names a concrete verb and resource ('Full website audit of one URL') and enumerates the four audit dimensions (WCAG 2.1 A/AA via axe-core, page speed/weight, on-page SEO, HTTP security headers) plus the composite output ('one overall score and the top issues'). It implicitly separates itself from narrower siblings like seo_audit or http_security_headers by promising everything 'from a single load in a real browser', but it never names those alternatives explicitly.

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

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

Three concrete use cases are given: a site or client report, a pre-launch check, and competitor comparison. That is clear positive guidance, but there is no when-not-to-use guidance and no routing to the single-purpose siblings (seo_audit, http_security_headers) for users who only need one dimension.

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

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

Goes well past the annotations: parallel fetching, per-page failure isolation via 'statuses with its reason and the rest still answer', a static-only limitation, a 20,000 character per-page ceiling, and a full cost model ($0.01/call, first 25 free, failed calls free, repeats not free). The charging note independently explains why idempotentHint is false, which the annotation alone would not convey.

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 and return contents, and no sentence is filler. The billing and safety clauses are crammed into long semicolon-chained sentences at the end, which slightly hurts scannability.

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 carries the return contract and does it: field names (text/Markdown, title, author, published date), the statuses array and its per-page reason semantics, and the truncated-length limit. Combined with the static-only caveat and cost, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real value: it frames urls as 'the request shape search APIs use (urls as a list)' and supplies a concrete example call, clarifying the one-to-five and multi-URL semantics. It does mention the 20,000 cap without the 4000 default, so the maxChars default still only comes from 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 verb and resource ('Read one to five public web pages in one call') plus exactly what is returned: clean text or Markdown, title, author, published date. It is clearly separable from siblings such as search (which finds URLs), html_to_text (which converts provided markup) and extract_rendered (which implies JS rendering), because it declares 'Static HTML, Markdown and plain text'.

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

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

Gives a concrete usage cue, 'Use to read search results in one call', which tells the agent when to reach for this over repeated single-URL fetching. It stops short of naming alternatives or exclusions (e.g. what to use for JS-rendered pages or for already-fetched HTML), so routing for edge cases is left to inference.

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

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

Annotations already cover read-only/open-world/non-idempotent, but the description adds real context on top: per-call pricing, 25 free calls, free failures, and the practical consequence that repeats cost money. It also surfaces the CC BY-SA attribution obligation, a behavioral constraint an agent must honor that appears nowhere in the structured fields.

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

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

Front-loaded with what the tool returns, followed by usage, an example, then cost and safety notes — a sensible ordering with little filler. The clause 'Reads or computes only and changes nothing' restates readOnlyHint=true and is the one genuinely redundant sentence.

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 correctly takes on the burden of describing the return shape (grouped by part of speech, examples, page link, attribution), and it also covers cost and billing behavior. An agent has everything needed to call this correctly and interpret the result.

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

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

Schema coverage is 100% with a single required 'word' parameter already documented in the schema. The inline example (word=serendipity) adds a small illustrative touch but no syntax or format guidance beyond what the schema provides, 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: a dictionary definition of an English word sourced from Wiktionary. It further specifies the shape of the result (grouped by part of speech, example sentences, page link, attribution), which cleanly separates it from siblings like wikipedia or search that return prose or result lists.

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?

Names concrete use cases (writing help, vocabulary, translation checks, word games) so an agent knows when this is the right tool. It stops short of explicit exclusions or naming an alternative for cases like encyclopedic background, which would be needed for 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?

Beyond the read-only annotations, the description discloses important operational behavior: static HTML only, no JavaScript rendering, output limits (default 20,000, max 100,000 characters), input limit 2 MiB, billing per call, free failed calls, and that repeated calls are charged. These are meaningful details an agent needs before invoking the tool.

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

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

The description is front-loaded with the core purpose and is dense with useful constraints. It includes minor redundancy, such as restating the read-only nature already covered by annotations and giving an example URL despite url being required in the schema, but most sentences carry operational 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?

With annotations covering safety, an output schema present, and full schema parameter descriptions, the remaining description is complete for correct invocation. It covers rendering limits, authentication/paywall exclusions, output size limits, pricing, and 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?

Schema description coverage is 100%, so the schema already defines url, format, section, and maxChars in detail. The description adds little parameter-specific meaning beyond mentioning the optional section ID and default/max output characters, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: fetch a public web page URL and return clean LLM-ready text or Markdown. It also names the content extracted (main content, code blocks, tables, links, headings) and distinguishes the no-JavaScript path from the sibling rendered option.

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

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

It explicitly says to use this to read docs or articles, and it names the alternative for JavaScript rendering via /extract/rendered. It also states clear exclusions: no logins or paywalls.

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

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

Annotations already declare readOnly, openWorld, non-destructive and non-idempotent. The description adds useful context beyond them: up to 15 seconds waiting for network settle, public pages only, and per-call pricing including failed calls being free. It stops short of describing the returned structure or truncation behavior directly, relying on '/extract' for output semantics.

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 key differentiator and usage trigger are front-loaded, and the description is dense without obvious repetition. It is slightly run-on, especially the pricing and safety clauses appended at the end, but every sentence carries useful 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 four-parameter extraction tool with no output schema, the description covers the important operational facts: rendering behavior, latency wait, public-only access, failure guidance, and cost. It relies on the sibling '/extract' for exact output format, which is a minor completeness gap.

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 four parameters are already documented in the schema. The description only supplies an example url and does not add meaning for format, section, or maxChars 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?

The description states a specific verb and resource: rendering a page in a real browser and returning its text/Markdown. It explicitly contrasts itself with the sibling /extract tool, so an agent can tell the two apart without opening schemas.

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 an explicit condition for use: when /extract returns EXTRACTION_EMPTY or too little text for a page readable in a browser. It also states the public-page/no-login constraint, which tells the agent when this tool is not applicable.

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

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

Goes well beyond the annotations: caps of 50 items and 2 MB, lenient parsing, a 422 for non-feed pages that is uncharged, pricing and free-tier rules, and the explicit note that repeats are not free (consistent with idempotentHint=false). The 'reads or computes only and changes nothing' statement aligns with readOnlyHint=true rather than contradicting 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?

Front-loads what the tool returns, then limits, failure behavior, use cases, and pricing in a sensible order. The opening sentence is long and packs return fields into a run-on list, but 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?

With no output schema, the description fully specifies the response shape and field formats (ISO 8601 dates, plain-text summaries). Size limits, error behavior, and cost are all covered, so an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so both parameters are already documented, including the web-page-that-links-to-a-feed case. The description adds only the item cap and an example URL, so it stays at the baseline for a fully documented schema.

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

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

States a specific verb and resource ('Read a public RSS 2.0, RSS 1.0 or Atom feed') and enumerates the returned fields (title, link, date, summary, author, id). This clearly separates it from sibling page-scraping tools like extract, contents, or url_meta.

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 guidance ('follow news, blogs, release notes or podcasts without scraping pages') and a worked example URL. It implies the alternative (page scraping) but does not name a specific sibling tool to use instead in edge cases, such as when the URL is not a feed.

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

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

Annotations already declare read-only, non-destructive and open-world, and the description adds genuinely new behavioral context: the 15 MB size ceiling, per-call pricing via x402 USDC or a card key, 25 free calls, failed calls free, and the explicit warning that repeats are charged (which explains the idempotentHint=false). The 'reads or computes only and changes nothing' clause reinforces rather than contradicts the annotations.

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

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

Front-loaded with capability, then example, then pricing. Dense but nearly every clause carries information; the pricing/billing sentence is long but material for an agent deciding whether to call. Minor trim possible without loss.

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 enumerating the returned fields (format, width/height, EXIF make/model/lens/date/exposure/aperture/ISO/focal length/orientation/software, GPS lat/lon/altitude) and conditioning GPS on availability. An agent knows exactly what it will get back and under what conditions.

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 only one parameter at 100% schema coverage, the schema already defines 'url'. The description still adds value by specifying the accepted formats (JPEG, PNG, GIF, WebP), the 15 MB limit, and a working example URL, giving the agent confidence about what constitutes a valid input.

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

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

Opens with a specific verb+resource ('Read an image's metadata from its URL') and enumerates exactly what comes back: format, dimensions, and a detailed EXIF field list including GPS. This is far more specific than the sibling 'url_meta' or 'screenshot' and lets an agent distinguish an image-EXIF reader from a generic web-page metadata 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?

Gives three concrete usage scenarios ('check where and when a photo was taken, verify an upload, or strip-check images before publishing') plus a runnable example URL. It does not name an alternative or state when NOT to use it (e.g., use url_meta for HTML pages), so it falls short of the explicit when/when-not bar.

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

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

Annotations already cover safety (readOnly, non-destructive, open-world, non-idempotent), and the description adds substantial extra context: Brave licensing restrictions (no storing/resale/model training), 503 on upstream failure with no charge, and $0.01/call pricing with failed calls free. These are behavioral traits an agent cannot get from the annotations alone.

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

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

Dense but front-loaded: purpose and returns come first, then limits, legal terms, and pricing. Minor waste from restating cost twice ($0.01/call and "each call is charged") and from re-declaring the read-only nature already in annotations.

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

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

With no output schema, the description compensates by naming the return fields (title, URL, snippet, publisher domain and age) plus failure mode and pricing. Nothing an agent needs to invoke this correctly appears to be missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by stating the 1-20 result range, describing freshness as past day/week/month, and giving a query example. It stops short of enumerating the exact freshness string values, leaving that to 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 verb+resource ("News headlines on any topic... from the Brave Search API's news index") and lists the returned fields, making the resource concrete. It separates itself from the general `search` sibling only implicitly via "news index" rather than naming the alternative, 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?

Gives a clear usage trigger ("Use when an agent needs current news on a topic") plus a worked example (q=bitcoin ETF) and warns that repeat calls are billed, discouraging redundant invocations. It never says when NOT to use it or explicitly routes to siblings like `search` or `pack_news_sentiment`, so no exclusions are provided.

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

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

Annotations already cover safety (readOnly, non-destructive, open-world, non-idempotent), yet the description adds genuinely new behavioral facts: $0.01 per call via x402 USDC or a card key, failed calls are free, and repeated calls are not free. It also discloses a licensing constraint ('results are for immediate use only (Brave API terms)') that no structured field conveys.

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 purpose, then usage, then cost and constraints in a single dense block. The opening clause largely repeats the title, which is minor waste, but the pricing and licensing sentences each carry real 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 three-parameter search tool with no output schema, the description covers result fields, result cap, freshness options, cost model, failure pricing, a licensing restriction and a usage example. Nothing an agent needs before calling it is missing.

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

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

Schema coverage is 100%, so 'q', 'count' and 'freshness' are already documented in the schema. The description restates the 1-20 range and the day/week/month freshness options and adds only a sample query value, which is marginal added meaning over 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 verb+resource (news search) and names the underlying source ('Brave news index') along with returned fields. It does not explicitly distinguish itself from close siblings like 'news', 'feed' or 'pack_news_sentiment', so an agent must infer the boundary, but the operation itself is unambiguous.

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

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

'Use when an agent needs the latest news or headlines on a company, coin, person or event' gives a concrete usage context plus a worked example (q=bitcoin ETF). There is no explicit when-not guidance or named alternative tool, which keeps it below 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?

Annotations only declare readOnly/openWorld/idempotent-false/destructive-false; the description adds substantial context beyond that — per-call cost ($0.01 via x402 USDC or credits key), failed calls free, an explicit warning that repeats are not free (explaining the non-idempotent hint in cost terms), licensing limits on reuse, and hard caps of 10 articles within a day/week/month window. That is unusually rich disclosure for a read-only 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?

It is front-loaded with the capability and output shape, and each subsequent sentence (limits, disclaimer, licensing, use cases, pricing) adds a distinct fact. The single dense paragraph blends pricing and licensing into the middle, which could be ordered better, but there is little 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?

With no output schema, the description carries the burden of describing return values and does so field by field, plus aggregates; it also covers cost, failure pricing, and recency caps. An agent has everything needed to decide and call correctly for a three-parameter tool.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including the 1-10 count range and the day/week/month freshness values. The description only restates those ranges and adds an example value (q=bitcoin), so it meets but does not exceed 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?

The description names a specific resource (news headlines on a topic) and states exactly what is produced: title, URL, publisher, age, plus a DistilBERT positive/negative score and the balance across articles. That is clearly distinct from the raw `news` sibling, though the alternatives are never named explicitly, so differentiation is inferred 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?

"Use for a market mood check, brand monitoring or a news brief" gives concrete use cases, and "Not a market signal" plus "results are for the caller's immediate use only (Brave API terms)" mark boundaries on interpretation and reuse. What is missing is an explicit routing statement telling the agent when to pick `news` or `pack_web_research` 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?

Goes well past the annotations: per-call charge of $0.01 (x402 USDC or card key), first 25 free, failed calls free, and 'repeats are not free', which explains why idempotentHint is false despite being read-only. It also discloses the key execution constraint, 'Server HTML only', i.e. no JS rendering — exactly the kind of trap an agent would otherwise fall into.

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: the capability enumeration comes first, usage second, and commercial/payment terms last where they can be skimmed. The single pricing sentence is dense but carries genuinely decision-relevant facts; a slightly tighter split would be cleaner.

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 listing the returned sections (title/description lengths, canonical, headings, alt text, structured data, score, issues, keywords, OG/Twitter, favicon, robots.txt sitemaps). Combined with the server-HTML caveat and cost model, an agent has everything needed to call it or reject 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?

Only one parameter and schema coverage is 100% ('Absolute http(s) URL of the page'), so the schema does the work. The description adds a worked example (url=https://www.wikipedia.org/) that shows expected granularity, which is modest but real added value.

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

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

Opens with a specific verb+resource ('on-page SEO analysis of a URL') and then enumerates exactly what is computed: audit fields, keyword/two-word density, social preview, favicon, robots.txt/sitemaps. That enumeration is what distinguishes it from siblings like seo_audit, url_meta, url_favicon, robots and text_keyword_density — it is explicitly the bundle.

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 before publishing, for an SEO report or to compare a competitor's page' gives concrete usage contexts, and 'Cheaper than the tools one by one' signals it supersedes the singles. It never names the actual alternative tools (seo_audit, url_meta, pack_website_audit), so the agent must infer the routing, and no when-not-to-use case is given.

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

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

Beyond the readOnly/openWorld annotations, the description discloses pricing ($0.01/call), that failed calls are free, that repeats are charged, that results cannot be stored/resold/trained on, and that unreadable pages are listed with reasons. These are important operational constraints an agent would not know from annotations alone.

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 action and return shape, then usage, example, and pricing/licensing constraints. It is somewhat dense but mostly earns its length, with minor redundancy around charged repeats and read-only behavior already covered by annotations.

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

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

For an open-world paid research tool with a fully described schema and no output schema, the description covers what it returns, how unreadable pages are handled, usage conditions, cost, and legal restrictions. An agent has enough information to call it correctly.

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

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

Schema description coverage is 100%, so all three parameters are already documented in structured data. The description mentions reading 1-5 pages, clipping to the caller's length, and gives a q example, but adds no real syntax or constraints beyond the schema; baseline 3 is appropriate.

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

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

States a specific compound action: Brave web search followed by reading the top 1-5 result pages in parallel with titles and URLs. This clearly distinguishes it from a bare search or separate page-extraction workflow.

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 says to use it when an agent needs current, sourced information in one step instead of a search plus several page reads, and gives an example query. It does not explicitly name sibling tools or say when not to use it versus search, wikipedia, or papers, but the usage context is clear.

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

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

Goes well past the annotations: discloses sanitisation rules (no scripts, styles, frames or forms), content moderation, noindex serving, the 7-day expiry, pricing at $0.01/call via x402 or a card key, and that failed calls are free. It also explains why repeats cost money, which gives concrete meaning to idempotentHint=false.

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 action, limits and return value before the usage guidance and pricing. It is a dense single paragraph, but every clause carries information an agent needs; only the pricing sentence is slightly over-packed.

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 three-parameter tool with no output schema, the description covers the return value (a public URL), its lifetime, the content constraints, and the cost model. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents html, title and days with defaults and ranges. The description restates the 200,000-character limit and the 7-day validity but adds no format or syntax detail beyond what the schema supplies.

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 ('Host a static web page'), names the inputs and the output ('a public URL at once'), and gives the lifetime. It never mentions the near-identical sibling page_publish, so an agent cannot tell the two apart from the description alone.

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

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

Gives concrete use cases: handing a person a report, dashboard or summary, or sharing results between agents. It does not state when not to use it or name page_publish as the alternative, which is the main routing gap for this tool.

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

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

Beyond annotations, the description discloses sanitisation rules (no scripts/styles/frames/forms/event handlers; links and https images survive), content moderation, storage, noindex serving, expiry limits, pricing ($0.01/call), failed-call policy, and repeat-call cost. These are substantive behavioral details an agent could not infer from annotations alone.

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 paragraph is dense but front-loaded: purpose and return format come first, then behavioral constraints and pricing. Every sentence carries operational information, though the pricing/support details make it slightly overstuffed for a single paragraph.

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

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

With no output schema, the description still explains what the caller receives (a public URL at /p/<id>) and the page's lifetime. Annotations cover the safety profile, and the description fills in sanitisation, moderation, and cost behavior. An agent has enough to invoke this correctly.

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

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

Schema coverage is 100%, so the schema already documents html, title, and days with defaults and limits. The description mostly repeats those constraints ('up to 200,000 characters', 'optional title', 'valid up to 7 days') rather than adding new syntax or edge-case semantics. Baseline 3 is appropriate.

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

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

The description states a precise verb+resource ('Publish an HTML page and get a public URL') and clarifies scope: sanitisation, moderation, storage, and serving at /p/<id>. This is clearly distinguishable from every sibling tool, which are extraction/research utilities rather than output-hosting tools.

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

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

It gives clear when-to-use guidance: 'hand a person a report, table or summary your agent produced, or to share results between agents.' It does not name explicit alternatives or exclusions, but the intended context is unambiguous.

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

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

Annotations already declare read-only, open-world, and non-destructive behavior. The description adds important non-schema context: pricing, payment methods, a 25-call free tier, free failed calls, and the fact that repeated calls are charged. It duplicates the read-only/no-change message somewhat, but the cost and payment details are meaningful behavioral disclosures.

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 purpose and scope, then proceeds through use cases, example, and pricing. It is mostly efficient, though the charging details are slightly repetitive across the final two sentences.

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 usefully enumerates returned fields such as title, authors, year, venue, citation count, DOI link, and abstract. It covers parameters, limits, pricing, and intended use. Minor gaps like sorting behavior or query syntax are not critical for correct invocation.

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 mentions the optional fromYear filter and 20-result limit, but those restate schema details; the query example adds a small amount of guidance without deepening 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 gives a specific verb and resource: search research papers across journals, conferences, preprints, and books via Crossref. It also lists the returned metadata. It is clearly an academic-paper search rather than a general web search, though it does not name sibling tools or explicitly contrast itself with them.

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 contexts: research agents, literature reviews, fact-checking against published work, and finding citation DOIs. It does not state when not to use the tool or explicitly point to alternatives such as general search or Wikipedia, but the intended usage is easy to infer.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=false, and the description reinforces both: 'Reads or computes only and changes nothing' and 'each call is charged, so repeats are not free' explains why the call is not idempotent. It goes well beyond annotations with size limits, failure modes that are billed at zero (scanned PDFs, encrypted files, non-PDF URLs), arXiv abstract-link handling, and full pricing/auth mechanics.

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 action, output, and limits, then failure modes, then pricing. It is on the long side and the charging point is made twice ('Price $0.005/call' and 'each call is charged, so repeats are not free'), but nearly every sentence carries operational 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?

For a four-parameter read tool with no output schema, the description covers return contents, pagination controls, size and page caps, per-failure-mode behavior, and cost/auth. An agent has everything needed to decide to call it and to interpret the result.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the page-window concept ('Choose a first page and how many pages to read (up to 200)') and that maxChars caps output, but adds little syntax or default behavior beyond what the schema already documents for each 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?

Opens with a specific verb+resource: 'Extract the text of a PDF from its URL', and states the output shape (page-by-page text plus title, author, page count, character counts). This clearly separates it from generic siblings like 'extract', 'contents' or 'summarize', which would not necessarily return raw PDF text.

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

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

Gives concrete use cases ('read papers, invoices, reports and manuals into an agent') and a worked example URL, plus explicit constraints (public PDF, up to 10 MB, 200-page cap) and failure conditions. It does not explicitly compare itself to sibling tools such as 'extract' or 'contents', so an agent must infer the routing rather than being told.

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

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

Annotations already declare read-only, open-world, non-destructive behavior, but the description adds useful operational context: the 4xx missing-file behavior, the returned fields, pricing, failed-call charging, and repeat-call cost. This goes well beyond what the annotations provide and does not contradict them.

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 definition is front-loaded with the purpose, rule semantics, return values, and usage guidance. It is mostly efficient, though the pricing sentence and the later 'each call is charged' clause are somewhat redundant.

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

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

With no output schema, the description still explains the return fields and the missing-robots.txt edge case. Combined with the fully documented two-parameter schema and the annotations, an agent has enough information to invoke it correctly.

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

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

Schema coverage is 100%, so both 'url' and 'agent' are already documented in the input schema. The description provides an example URL and mentions crawler/user-agent rules, but it does not add much parameter meaning beyond the schema descriptions.

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

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

The description opens with a specific verb and resource: 'Read a site's robots.txt and say whether a crawler may fetch a URL.' It also distinguishes the tool from the related sitemap use case, so an agent can identify it 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?

It explicitly says to 'Use before scraping or crawling a site politely' and routes sitemap URL exploration to the separate sitemap tool. The missing-robots.txt behavior is also stated, giving clear context for when the tool applies.

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

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

Goes well beyond the annotations: it discloses pricing ($0.002/call, first 25 free, failures and bot walls uncharged), explains why repeats cost money (reinforcing idempotentHint=false), caps output at 100,000 characters, and limits scope to static HTML rather than rendered pages. That is exactly the extra context annotations cannot carry.

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

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

Purpose is front-loaded and most clauses earn their place (formats, limits, pricing, JS caveat). It is a dense semicolon-chained paragraph, though, and the 'Example: url=https://example.com' clause is near-zero value padding.

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

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

With no output schema, the description still characterizes the return value (clean text or Markdown with headings, code blocks, tables and links preserved) and the size cap. Combined with pricing and the static-vs-rendered distinction, an agent has everything needed to call it correctly and predict cost.

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

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

Schema coverage is 100%, so url, format, section and maxChars are all already documented. The description echoes the Markdown/text format and the 100,000-character ceiling but says nothing about the optional 'section' parameter (visible HTML ID), so it adds almost no meaning beyond the schema — baseline 3.

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

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

States a specific verb and resource ('fetch any public web page URL') and the output shape ('main content as clean text or Markdown'), which separates it from siblings like html_to_text or extract. It also routes JavaScript-rendered pages to /extract/rendered, so an agent can tell it apart from the rendered-page variant without opening 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?

"Use to read articles, docs and product pages at scale" gives concrete usage, and the JS-rendering note implicitly excludes one class of pages. It stops short of naming the sibling tool (only the /extract/rendered path) and gives no guidance on when to prefer extract, contents, or search_web instead.

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

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

Beyond the annotations it discloses that JS is executed, the exact image dimensions and encoding, the fullPage height cap of 4000 px, the extra return fields, and — critically — the billing model: $0.01 per call, failed calls free, and repeats are not free. The cost and repeat-charge warning is exactly the kind of behavior an agent cannot get from readOnlyHint/openWorldHint.

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 render-and-return statement, then scoping, use cases, example, and pricing — every clause carries information. Minor redundancy in 'Reads or computes only and changes nothing', which largely restates readOnlyHint/destructiveHint=false.

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 fully carries the return burden: image format, width, base64 encoding, plus final URL, status and title. For a two-parameter tool with annotations already covering safety, cost disclosure and the fullPage caveat, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so both parameters are already documented, including the 1280x800 default and 4000 px cap that the description restates. The only added value is the concrete example URL format, which is marginal; baseline 3 applies 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?

The description names a specific verb and resource — render a public page in headless Chrome with JavaScript executed and return a JPEG screenshot plus final URL, HTTP status and page title. That return payload also separates it from siblings like extract_rendered or url_meta, which an agent can distinguish without opening 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?

It gives concrete usage contexts (visual checks, page previews, monitoring, feeding vision models) and a worked example call. It stops short of naming an alternative tool or stating when not to use it, so the agent must infer that text-oriented siblings are preferable when pixels are unnecessary.

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 annotations already marking it readOnly, openWorld and non-destructive, the description adds real behavioral context: JavaScript is executed in headless Chrome, the image is 1280 px wide base64, fullPage caps at 4000 px, and the response includes final URL, status and title. It also discloses cost ($0.01/call via x402 USDC or card key, failed calls free), which explains the non-idempotent hint.

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

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

Dense but front-loaded: capability and output come first, then usage, then pricing. The semicolon-chained clauses make it heavier than needed and the billing details sit awkwardly mid-paragraph, but no sentence is pure 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?

There is no output schema, so the description carries the return shape and it does — image format, width, encoding, plus the final URL, HTTP status and title. For a two-parameter read-only tool, an agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3. The description's note that fullPage=true captures up to 4000 px largely restates the schema's own 'max 4000 px' text, and the example URL adds no semantic depth, so little is contributed beyond structured fields.

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 (render a public page and get a JPEG screenshot) plus concrete return payload: 1280 px wide JPEG in base64, final URL, HTTP status and title. It does not differentiate from the sibling tool named 'screenshot', which is the main ambiguity left.

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 use contexts (visual checks, previews, monitoring, archiving a page as an agent sees it) and warns that repeats are charged, but never names an alternative or says when not to use it, e.g. versus the sibling 'screenshot' or 'extract_rendered'.

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

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

Beyond the annotations' safety profile, the description discloses pricing ($0.01/call via x402 USDC or card key), that failures return 503 and are uncharged, that repeats are charged, and licensing terms prohibiting storing, resale or model training. This is exactly the operational context annotations cannot convey.

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 front-loaded block that leads with what is returned, then filters, then cost and terms. The legal and pricing sentences are dense but each carries information an agent needs; only the index/cost details could be trimmed slightly.

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 15-parameter tool with no output schema, the description covers return fields, failure mode, cost and usage restrictions, which is substantial. It leaves the exact response envelope and pagination/limit behavior implicit, but no critical gap blocks correct invocation.

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 every one of the 15 parameters is already documented and the baseline is 3. The description adds only a light layer ("optional domain, date, category and phrase filters", summaries of the top 10 pages), without clarifying interactions such as textChars plus highlights on large result counts.

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?

"Exa-style web search" names a specific verb and resource, then enumerates the return fields (title, URL, snippet, published date, favicon) and the Brave index backing it, so the agent knows exactly what the tool produces. It stops short of differentiating from siblings like news, contents or extract, which overlap in scope.

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 when an agent needs current information or sources from the open web" plus a concrete example (q=x402 payment protocol) gives clear positive guidance. There are no exclusions or pointers to sibling alternatives (news for headlines, contents for a known URL), so the agent must infer when to prefer them.

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

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

Beyond the annotations (readOnly, openWorld, idempotent=false, non-destructive), the description discloses non-obvious behavioral facts: results are licensed for immediate use only (Brave terms), failed calls are free while every successful call costs $0.01 via x402 USDC or card key, and repeats are not free. Those billing and licensing constraints materially change how an agent should plan retries and caching, and none of them appear in structured fields.

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

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

The purpose and cost model are front-loaded, and each sentence carries operational information. There is minor redundancy: 'failures are uncharged' and 'failed calls free' repeat the same fact, and 'each call is charged, so repeats are not free' restates the price line.

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 15-parameter tool with no output schema, the description covers purpose, returned fields, optional enrichments, filtering, pricing, licensing and failure behavior, which is close to sufficient. It stops short of describing the shape of highlight/summary objects or pagination/count semantics, so an agent still relies on the schema for output expectations.

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

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

Schema description coverage is 100%, so the baseline is 3; the description goes slightly beyond by grouping the optional capabilities into named feature families (page text, highlights, per-result summary, and domain/date/category filters). It adds no per-parameter detail for count, numSentences, highlightsPerUrl, includeText or excludeText, so it is a mild improvement rather than a full semantic layer.

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 plus resource ('search the web and get the top results as JSON') and enumerates the returned fields (title, URL, snippet, published date, domain), so the tool's function is unmistakable. It does not, however, distinguish itself from close siblings such as 'search', 'news_search', 'papers' or 'wikipedia', so an agent must infer the boundary on its own.

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 when an agent needs current information, sources or links from the open web' plus the concrete example 'q=x402 payment protocol' gives clear positive guidance on context of use. There are no explicit exclusions or named alternatives for cases like news-only or academic lookups, which is the main gap given the many overlapping siblings.

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

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

Adds substantial context beyond annotations: it reads the server's raw HTML with no JavaScript, caps at 1 MB, changes nothing, and explains the charged-per-call pricing (x402 USDC or card key, first 25 free, failed calls free). That pricing note also explains why idempotentHint is false, which the annotations alone would leave confusing.

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

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

The purpose is front-loaded and every clause adds a distinct fact. The first sentence is very long and the pricing tail is dense, but none of it is filler for an agent that must weigh cost before calling.

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

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

With no output schema, the description must describe return contents — and it does so exhaustively, including the issue list and score. Input constraints (1 MB, no JS) and cost model are also covered, leaving nothing an agent needs to call correctly 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% and the single parameter is already described as an absolute http(s) URL, so the schema carries most of the load (baseline 3). The description contributes a concrete example (url=https://www.wikipedia.org/), which is a modest but real addition.

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 precise verb and resource ('on-page SEO audit of one URL') and then enumerates the exact fields returned (title/meta lengths, canonical, H1/H2, alt-text gaps, OG/Twitter, JSON-LD, link counts, word count, issues, 0-100 score). That enumeration cleanly separates it from adjacent siblings like url_meta, domain_report and pack_seo_toolkit.

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 ('check a page before publishing or to compare competitors') and a worked example with a real URL. It does not name an explicit alternative or state when NOT to use it (e.g. vs. pack_seo_toolkit or url_meta), 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?

The annotations already establish read-only, open-world, non-idempotent behavior, but the description adds important operational detail: 512 KiB/1000-entry bounds, warnings on large sitemaps, invalid XML/execution errors not charged, empty matches charged, pricing, free quota, and that repeats are not free. This goes well beyond the structured annotations without contradicting them.

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

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

The description is front-loaded with the core behavior, limits, and usage guidance, and it remains dense rather than padded. There is slight redundancy around charging and repeat calls, but most sentences earn their place by covering billing, limits, or scope.

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?

An output schema exists, so return-value details need not be repeated, and the annotations plus full schema coverage handle safety and parameters. The description supplies the remaining operational context an agent needs: bounds, non-crawling behavior, error/charging rules, and the intended relationship to /extract.

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

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

Schema description coverage is 100%, so the schema already fully documents url, offset, maxUrls, and contains. The description mentions filtering and pagination at a high level but does not add parameter-specific meaning beyond what the schema provides.

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

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

The description states a specific verb and resource: it reads one public XML sitemap or sitemap index and returns structured URLs and source-reported dates. It also distinguishes its scope from crawling/extraction by noting gzip support, filtering, pagination, and that it does not follow child sitemaps.

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

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

It explicitly says to use this tool to find which pages of a docs site to read before calling /extract, giving a concrete upstream role relative to a sibling tool. It also states exclusions: does not crawl pages or follow child sitemaps.

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

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

Annotations already declare readOnly=true, destructive=false, idempotent=false and openWorld=true, so the safety bar is low. The description nonetheless adds cost details ('$0.01/call via x402 USDC or a card key', 'failed calls free', 'repeats are not free'), which explains why idempotency is false, and describes what happens internally (navigation and boilerplate stripped before summarizing).

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 opening sentence front-loads the output shape and the next explains the mechanism, so an agent gets the gist immediately. The closing stack of pricing and 'changes nothing' reminders is a touch repetitive with the annotations, but every sentence still carries information.

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

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

For a one-parameter tool with no output schema, the description supplies the return shape ('short summary ... plus three to six key points'), the failure/compatibility boundary (HTML only), pricing, and the sibling handoffs. Nothing needed to invoke it correctly is missing.

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

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

The single parameter has 100% schema coverage, including 'Absolute http(s) URL', so the schema already carries the meaning. The description adds only a concrete example URL and the 'Give a URL' framing, which is helpful but not substantially beyond the schema. Baseline 3 fits.

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 ('fetches the page ... summarizes the main text with an LLM') and immediately names what it is not: 'HTML pages only; for a PDF use pdf_text' and 'For the full text use extract.' An agent can separate it from extract, contents, pdf_text and page_publish 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 explicit use cases ('research, news triage, link previews and deciding whether a page is worth reading in full') plus an exclusion with a named alternative for PDFs and for full text. It also warns that repeats are not free because each call is charged.

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?

Adds substantial context beyond the annotations: ~110 fingerprints, 'server HTML only' (a real limitation given rendered siblings), per-call pricing with 25 free and failed-calls-free, and an explicit note that repeat calls are charged. It also restates the read-only/non-mutating profile in operational terms ('reads or computes only and changes nothing'), consistent with readOnlyHint=true and destructiveHint=false.

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 category list, then limitations, then use cases and pricing. Dense but every clause carries information; the pricing sentence is somewhat packed and could be split for scannability.

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

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

For a single-parameter, read-only detection tool with no output schema, it covers what is returned ('each with the evidence that matched'), the data source, the fingerprint library size, and cost behavior. An agent has everything needed to decide and invoke 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?

Only one parameter, and the schema already documents it at 100% coverage ('Website or page URL'). The example (url=https://vercel.com/) reinforces the expected format, which is a modest but real addition over 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 verb ('detect') and resource ('technologies behind a website') and enumerates the exact categories returned (CMS, JS framework, analytics, CDN, hosting, backend). This clearly separates it from siblings like url_meta or seo_audit, which do not fingerprint a stack.

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

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

Gives concrete use cases ('lead research, competitor analysis or sales prospecting') and a worked example URL, which tells the agent when to reach for it. It stops short of naming alternatives or exclusions (e.g., when to prefer extract_rendered for JS-heavy sites), so a 4 rather than 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?

Beyond annotations, it discloses pricing ($0.01/call via x402 USDC or card key), free tier (first 25 free, failed calls free), and that each call is charged so repeats are not free – clarifying the non-idempotent hint. It also states it 'reads or computes only and changes nothing,' reinforcing the read-only annotation.

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 what the tool returns, followed by usage, example, and pricing. It is dense but every sentence contributes relevant information, though the pricing/charging sentence is slightly 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?

For a one-parameter tool with no output schema, the description thoroughly explains the return structure (icon list with sizes/types, manifest link, favicon.ico existence, absolute URLs, best-icon selection logic) and the charging behavior. Nothing an agent needs to invoke it correctly is missing.

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

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

With 100% schema coverage, the schema already documents the single 'url' parameter. The description adds only an example (url=https://github.com/), which is mildly helpful but not substantive beyond the schema baseline.

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

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

The description uses a specific verb ('Find') and lists exactly what is returned: every <link rel=icon>, shortcut icon, apple-touch-icon, mask-icon with size/type, the web app manifest link, /favicon.ico existence, as absolute URLs, plus the best-icon selection logic. This distinguishes it from siblings like url_meta, image_metadata, or seo_audit without needing their schemas.

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 concrete use cases: 'Use to show a site's logo next to a link, build bookmarks or enrich a company record.' This makes the intended context explicit, though it does not name a sibling alternative or state 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?

Adds substantial context beyond the annotations: 1 MB read cap, no JavaScript execution, no mutations, per-call pricing ($0.01 via x402/card key), first 25 free, failed calls free, and repeats are billed. That pricing detail also explains the idempotentHint=false annotation (repeat calls cost money) rather than contradicting 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?

Front-loads the core behavior and returned fields, then usage, then cost. Mostly tight, though the trailing 'reads or computes only and changes nothing' partially restates the annotations and the charged-per-call point is repeated.

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

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

No output schema exists, yet the description lists the return fields in detail, and with a single fully documented parameter plus rich annotations, an agent has everything needed to call this 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?

Only one parameter, and the schema already documents it at 100% coverage (absolute public http(s) URL). The description reinforces the 'public' constraint and supplies a concrete example URL, adding modest value beyond the schema.

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

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

Names a specific verb and resource (fetch a public web page's head, return link-preview metadata) and enumerates the returned fields. Clearly distinct from siblings like extract, extract_rendered, or url_favicon, which do different jobs.

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 three concrete use cases (build link previews, label citations, preview how a URL unfurls) and an example call. It does not, however, say when to prefer a sibling such as extract or seo_audit, so the routing decision is left implicit.

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

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

Adds substantial context beyond annotations: 10-hop cap, loop detection, SSRF protection ('every hop is checked before it is requested; redirects to private addresses are reported, not followed'), page not loaded, and per-call pricing with repeats not free. These details matter because idempotentHint=false is otherwise unexplained.

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

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

Purpose and safety behavior are front-loaded, use cases and an example follow, and pricing is last. Slightly heavy on billing detail ('x402 USDC or a card key (/credits)') for a tool description, but nothing is buried or 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?

No output schema exists, and the description fully specifies the return shape: every hop's status code and Location, final URL, total hops, timing, loop flag. Combined with the hop limit and private-address handling, an agent has everything needed to call it and interpret 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 coverage is 100% for the single url parameter ('Absolute http(s) URL'), so the schema already carries the semantics. The description only adds an example (url=http://github.com) and no format or edge-case guidance beyond what the schema states.

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: 'Follow a URL's redirects hop by hop ... return every hop's status code and Location' and explicitly covers short-link expansion. An agent can distinguish it from sibling url_meta (metadata), url_uptime (availability), and extract (page content) without opening any schema.

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

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

Gives concrete use cases: unshorten a link, check an HTTPS or www redirect, debug SEO redirect chains. It does not name a sibling alternative or an explicit when-not-to-use condition, which keeps it below 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?

The description discloses key traits beyond the annotations: timeouts and connection failures are returned as 'down with the reason, not as an error,' redirects are followed, and each call costs $0.01 with 25 free and failed calls free. These details clarify error semantics, cost, and the idempotentHint=false behavior (repeats are charged), which the annotations alone do not convey.

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

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

The purpose and output list are front-loaded in the first sentence, and the usage cases follow. The pricing and billing sentences are relevant but make the description slightly dense; it remains efficient 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, the description fully covers the return contract: status, up/down, response time, final URL, content type, server header, page size, and optional text match. It also explains failure semantics and billing, so an agent has everything needed to call and interpret the tool.

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

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

Schema coverage is 100% and both parameters ('url', 'contains') are already documented in the input schema. The description restates the optional text check and gives an example URL, but adds no new syntax or constraint information beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description opens with a precise verb and resource: 'Check whether a website is up right now,' then enumerates the exact outputs (HTTP status, up/down, response time, final URL, content type, server header, page size). It clearly distinguishes itself from sibling url_meta and url_redirects by framing the call as a live uptime probe with a specific diagnostic payload.

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: 'uptime monitoring, health checks before calling an API, or to confirm a deploy,' which gives an agent clear selection context. It does not explicitly state when not to use it or name a sibling as the alternative, so it falls short of the top score.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and critically idempotentHint=false; the description explains that last one by stating each call is charged and repeats are not free. It also discloses auth options (x402 USDC or card key /credits) and the free-tier behavior (first 25 free, failed calls free), which is real information beyond the annotation block. 'Reads or computes only and changes nothing' merely restates the annotations and adds no new 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?

It is front-loaded with the purpose and return shape, then usage, then commercial terms — a sensible order with little waste. The pricing clause is mildly redundant, stating '$0.002/call' and then again that 'each call is charged, so repeats are not free,' which could be tightened to one statement.

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

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

There is no output schema, so the description carries the burden of describing return values — and it does, listing five specific fields. Combined with the example call, pricing, and auth disclosure, an agent has everything needed to decide to call it and to pay correctly.

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

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

Schema coverage is 100%, so 'title' (Article title) and 'lang' (Language code, default en) are already documented in the schema. The description adds the notion of 'any language edition' and a title example, which helps frame the lang parameter, but supplies no syntax or format details beyond what the schema says. 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 states a specific verb and resource ('Short summary of a Wikipedia article') and enumerates exactly what comes back: title, one-paragraph extract, description, thumbnail, and page URL. That payload list alone separates it from siblings such as search, extract, news, or dictionary, which do not return a single citable article fact sheet.

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 ground an agent's answer in a quick, citable fact sheet' gives a clear reason to reach for this tool, and the concrete 'Example: title=Stockholm' shows the expected call shape. There is no explicit when-not guidance or named alternative (e.g., use search for open-ended querying, extract for full page text).

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