Agent Data Tools: Web and documents

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

Adds genuinely non-structured context: the $0.001 USDC-on-Base x402 payment per successful call and the CC BY-SA attribution obligation the caller must surface. It does not state failure modes or rate limits, so not a 5, but the payment and licensing disclosure is real value beyond 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?

One dense sentence covering return shape, then a use-case sentence and a pricing sentence. Front-loaded and mostly waste-free, though the use-case list is the least essential part.

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

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

No output schema exists, and the description compensates by describing the return structure (definitions grouped by part of speech, examples, page link, attribution) plus cost. Only failure/edge behavior is absent, which is minor for a single-param lookup.

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

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

Only one parameter (word), and schema description coverage is 100%, so the schema already carries the meaning. The description adds no constraints such as expected casing, single-word vs phrase, or language handling, 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 precise verb+resource+source: definitions of an English word from Wiktionary, grouped by part of speech, with examples, page link and attribution. An agent can distinguish this from siblings like wikipedia or ai_translate immediately.

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

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

Lists use cases (writing help, vocabulary, translation checks, word games) which implies when to call it, but gives no explicit when-not and does not contrast with the nearby wikipedia or ai_translate tools. Usage is implied rather than routed.

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 concrete operational traits: default 20,000 and max 100,000 output characters, 2 MiB input cap, exact failure semantics ('Empty pages, invalid sections, browser challenges and execution errors are uncharged'), and the payment model ('$0.002 in USDC on Base per successful call, paid with x402'). This also explains why readOnlyHint is false despite a read operation — the call spends money — so there is no contradiction.

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 every sentence carries information (limits, cost, failure handling), with no filler. It is dense to the point of being run-on, packing limits, exclusions, failure rules and pricing into a single block, 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?

For a paid, open-world fetch tool with an output schema already covering the return shape, the description supplies everything else an agent needs: input/output size caps, JS/auth/paywall limits, cost and currency, and which failures are free. Nothing material is missing before 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: what the HTML 'details' payload actually contains (code, tables, links, heading IDs, image alt text, unverified author/date provenance) and that section must be an 'exact HTML section ID' with URL fragments explicitly not selecting a section. The default/max char figures duplicate the schema, but the format-detail explanation is genuine 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?

The description gives a specific verb+resource ('Read public static HTML, Markdown or plain text') and immediately bounds the scope with negatives ('No JavaScript rendering, authentication or paywall access'), which implicitly separates it from siblings like html_to-text (converts supplied HTML), screenshot (renders JS) and pdf_text. It also enumerates what an HTML fetch yields (code, tables, links, heading IDs, alt text, author/date provenance), so an agent knows exactly what class of tool this is.

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

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

It states a positive use case ('Use to read docs or articles into context') and the exclusions ('No JavaScript rendering, authentication or paywall access') implicitly define when not to use it. However, it never names an alternative for those excluded cases (e.g. screenshot for JS pages), so routing to a sibling 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 only cover the generic safety profile; the description adds latency (waits for network up to 15s), an auth constraint (public pages only, no login), a failure-mode trigger (EXTRACTION_EMPTY), and a payment model ($0.01 USDC on Base via x402). The payment detail explains why readOnlyHint is false, so nothing is contradicted.

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?

Five short clauses, front-loaded with the differentiator ('Same output as /extract, but the page is first rendered'), and each remaining sentence carries distinct operational information. No filler.

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

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

Covers the cost, latency ceiling, access limits, and the error condition that motivates use, and points to /extract for output shape. Minor gap: it doesn't say what is returned if the 15-second network wait expires, which matters for a tool with no output schema.

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

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

Schema description coverage is 100%, so url, format, section, and maxChars are already fully documented in the schema. The description adds no parameter-level syntax or format detail, which is the expected baseline 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?

States a specific verb+resource (extract rendered page text) and explicitly contrasts it with the sibling /extract, explaining the rendering difference. An agent can distinguish it from extract, screenshot, and text_extract 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 an explicit trigger condition: use when /extract returns EXTRACTION_EMPTY or too little text for a page readable in a browser. This names the alternative and the condition that selects this tool over 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 behavior beyond the annotations: 50-item and 2 MB caps, lenient real-world parsing, 422 on non-feed pages with no charge, and the $0.002 x402 payment on success. The payment/charging detail also explains why readOnlyHint=false and idempotentHint=false, so the description and annotations are consistent rather than contradictory.

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

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

Four dense sentences with no filler: purpose and return fields first, then limits, then error/payment behavior. The cost disclosure is placed last where it belongs and every clause carries information an agent needs.

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

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

There is no output schema, and the description compensates by enumerating the returned feed-level and item-level fields. Combined with limits, error semantics, and pricing, 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 both parameters (url, limit) are already fully documented with types, ranges, and default. The description only restates the 50-item ceiling and the shape of returned items, adding no syntax or format detail beyond the schema; 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 ('Read a public RSS 2.0, RSS 1.0 or Atom feed') and enumerates exactly what is returned (feed title, link, description plus item title/link/date/summary/author/id). This cleanly separates it from siblings like sitemap, url_meta, html_to-text, or extract, which fetch pages rather than parsed feeds.

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

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

Gives clear context for use ('follow news, blogs, release notes or podcasts without scraping pages'), which tells the agent when this beats a generic page fetch. It stops short of naming specific alternative tools or exclusions (e.g., when to prefer sitemap or url_meta), so it is strong but not fully routing.

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 openWorldHint=true and destructiveHint=false, but the description adds the crucial fact that each successful call costs $0.003 USDC on Base via x402, which explains the non-readOnly/ non-idempotent hints. It still omits failure/refund behavior and rate limits, so it is helpful but not exhaustive.

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

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

It is one dense sentence plus a use-case sentence, front-loaded with what is searched and what is returned before the filters and cost. Nothing is wasted, though the return-field enumeration makes the opening clause long.

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

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

With no output schema, the description usefully lists return fields (title, authors, year, venue, citation count, DOI, abstract) and covers filters, result cap and payment cost. It lacks only edge-case behavior for an obviously simple query tool.

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

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

Schema coverage is 100%, so query, limit and fromYear are already documented in the schema with ranges and defaults. The description only restates the fromYear filter and the 20-result cap, adding no syntax or format detail 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 names a specific verb (search) plus the resource and its scope (scholarly literature across journals, conferences, preprints and books) and even enumerates the returned fields. No sibling tool covers literature search, so an agent can select this unambiguously.

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

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

It gives concrete when-to-use contexts: research agents, literature reviews, fact-checking a claim against published work, and finding a DOI for a citation. It stops short of naming when NOT to use it or an alternative tool, but no sibling overlaps this capability.

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 concrete limits (10 MB, up to 200 pages), output capping via maxChars, the exact failure modes that produce errors, and the crucial detail that these failures are 'uncharged.' It also spells out the paid-call mechanics ($0.005 USDC on Base via x402), which explains why readOnlyHint is false despite the read-like framing.

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 returns, then layers limits, failure modes, use case and pricing in a logical order where each sentence carries distinct information. It is somewhat clause-dense but not padded, so nearly every sentence earns its place.

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

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

With no output schema, the description fully carries the return-value burden, naming the returned text and metadata (title, author, page count, character counts). Combined with size/page limits, charging rules and failure conditions, an agent has everything needed 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 description coverage is 100%, so the schema already documents url, pages, maxChars and firstPage with ranges and defaults, making 3 the baseline. The description adds only light reinforcement ('choose a first page and how many pages to read', 'cap the output with maxChars') and no syntax or interaction detail 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 pairs a specific verb and resource ('Download a public PDF ... and return its text page by page') with concrete scope (public, up to 10 MB) and enumerates the returned fields. It is unambiguous about what the tool does, though it never names a sibling (e.g., text_extract or html_to-text) to disambiguate format handling.

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

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

It states the intended context explicitly ('Use to read papers, invoices, reports and manuals into an agent's context') and lists failure conditions (scanned PDFs without a text layer, encrypted files, non-PDF URLs). It stops short of naming an alternative tool for cases that fall outside PDF handling, so it lacks exclusions.

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

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

Goes well beyond annotations by disclosing the pricing/auth model ('$0.02 in USDC on Base per successful call, paid with x402'), that JavaScript is executed, the fixed 1280 px width, the 4000 px full-page cap, and the exact return payload. Open-world access is declared in annotations, but the cost and output-shape context here is genuinely additional.

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

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

Four tight sentences, front-loaded with the core action and output, then the fullPage caveat, use cases, and cost. No filler and nothing buried.

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

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

With no output schema, the description carries the return-value burden and does so completely (JPEG, final URL, status, title). Payment requirements and capture limits are also covered, so an agent has everything needed for a correct call.

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

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

Schema coverage is 100%, so both parameters are already documented, including the 1280x800 default viewport. The description restates the width and fullPage height cap but adds no new syntax or constraint beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource — 'Render any public web page in a real headless Chrome browser' — and specifies the exact artifact returned (base64 JPEG, final URL, HTTP status, page title). An agent can distinguish this from text-oriented siblings like extract or summarize without opening the schema.

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

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

Gives concrete usage contexts: 'visual checks, page previews, monitoring and feeding pages to vision models.' It lacks an explicit when-not or a named alternative (e.g. versus extract for text), so it stops short of full routing guidance, but the intended scenarios are 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?

The description adds substantial behavior beyond the annotations: gzip support, 512 KiB expanded input cap, 1000-entry cap, filtering and pagination behavior, non-charging for invalid XML and execution errors, charging for valid empty matches, and the $0.002 USDC x402 cost. These details are highly relevant for an agent deciding whether and how to invoke a paid, open-world read operation.

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

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

The description is dense but well structured: purpose first, then capabilities and limits, then exclusions, then billing behavior, then intended workflow. Every sentence carries operational information an agent needs.

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

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

Given that an output schema exists, the description does not need to explain return values in detail, and it already states that results are structured URLs with source-reported dates. It also covers constraints, billing, exclusions, and intended usage, leaving no major operational 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 the parameter descriptions already carry most of the load. The description still adds useful semantics not present in the schema, notably gzip support, the 512 KiB expanded-input limit, and the 1000-entry cap, though it does not add much per-parameter detail beyond that.

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

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

The description states a specific verb and resource: read one public XML sitemap or sitemap index as structured URLs and source-reported dates. It also distinguishes this from crawling or following child sitemaps, so an agent can tell it apart from page-fetching siblings like extract.

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 find which docs pages to read before calling /extract, and it states the negative boundary: it does not crawl pages or follow child sitemaps. This gives both when-to-use guidance and an explicit alternative workflow.

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?

Discloses behavior beyond the annotations: it fetches the page, strips navigation/boilerplate, and summarizes with an LLM. Critically it surfaces the payment requirement ($0.01 USDC on Base via x402), a cost/auth detail no annotation conveys and which helps explain the readOnlyHint=false. It does not describe latency, failure, or rate-limit behavior.

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

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

Four tight sentences, front-loaded with the outcome ('Give a URL, get...') before mechanism, use cases, and cost. Every sentence adds distinct information with no redundancy.

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

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

No output schema exists, so the description appropriately describes the return value (summary + 3-6 key points). With one required parameter and disclosed cost/processing, an agent has everything needed 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 description coverage is 100% with a single well-documented 'url' parameter, so the schema already carries the semantics. The description only restates 'Give a URL' without adding format or constraint detail (e.g. supported content types), 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 concrete verb+resource (summarize a URL/page) and specifies the deliverable shape: a short summary plus three to six key points. An agent immediately understands the input (a URL) and the output, and the operation is distinct from the fetch/extract-style siblings even though none is named.

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 lists intended contexts ('research, news triage, link previews and deciding whether a page is worth reading in full'), which gives clear when-to-use guidance. It stops short of naming an alternative tool or stating when NOT to use it (e.g. vs extract), so it is not a full 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?

Discloses concrete behavior beyond the annotations: 512 KB read cap, no JavaScript execution, and a $0.001 USDC-on-Base cost via x402. These are exactly the operational facts an agent needs. The description reads as a pure read op while readOnlyHint=false, but the per-call payment gives a plausible rationale for the non-read-only flag, so this is tension rather than a hard contradiction.

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

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

Three well-ordered sentences: capability and returned fields first, constraints second, use cases and cost last. The field enumeration is long but earns its place given there is no output schema; only minor trimming is possible.

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

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

With no output schema, the description compensates by listing the returned metadata fields. Combined with the size cap, no-JS guarantee, and payment cost, an agent has everything needed to decide whether and how to call 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 with 100% schema coverage, so the schema already documents the 'absolute public http(s) URL' constraint. The description reinforces 'public web page' but adds no new syntax or format detail 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?

States a specific verb+resource (fetch a page's head and return link-preview metadata) and enumerates exactly which fields come back. It is clearly distinguishable from siblings like screenshot, extract_rendered and html_to-text because it declares it reads only the head and never runs JavaScript.

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 names the intended use cases: build link previews, label citations, or check how a URL will unfurl before sharing. It does not name an alternative sibling or state when not to use it, so it stops short of a 5, but the 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?

Adds meaningful context beyond annotations by disclosing the pay-per-call cost model ($0.001 USDC on Base via x402), which explains why readOnlyHint=false despite this being a data lookup — the side effect is financial. It does not mention rate limits or latency, but the cost disclosure is the critical behavioral fact.

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

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

Three tight clauses: what it returns, when to use it, what it costs. Front-loaded with the payload and free of filler; every sentence earns its place.

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

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

With no output schema, the description compensates by enumerating the return fields, and it discloses the payment prerequisite an agent must know before invoking. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (lang, title) are already documented. The description reinforces 'any language edition' and the title-based lookup but adds no syntax or format detail beyond the schema. 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 ('Short summary of a Wikipedia article') and enumerates the exact payload (title, extract, description, thumbnail, page URL). An agent can distinguish this from siblings like summarize, papers, or extract 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?

'Use to ground an agent's answer in a quick, citable fact sheet' gives clear when-to-use context. It does not name alternatives (summarize/papers) or state when-not to use it, so it falls short of the explicit routing a 5 requires.

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