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

With no annotations and no output schema, the description carries the full disclosure burden. It usefully discloses the return format ('plain text (no HTML)') and rough size ('typically several paragraphs'), which is real behavioral value. It does not cover failure behavior for missing titles, disambiguation pages, redirects, or truncation limits, so it is only partially transparent.

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

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

Two sentences, zero filler, with the primary purpose and the sibling contrast front-loaded. Every clause earns its place and nothing is repeated from the schema.

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

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

For a 2-parameter read tool with no annotations or output schema, the description covers purpose, output format, and size — enough to call it correctly. Edge-case behavior (nonexistent titles, disambiguation, language fallback) is unaddressed, which keeps it short of fully complete.

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% — both `lang` (enum plus default) and `title` (with examples) are fully documented in the schema. The description adds nothing parameter-specific beyond what the schema already 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 ('Get a Wikipedia article's full plain-text extract by title') and immediately distinguishes itself from the `summary` sibling by contrast in length. An agent can tell exactly what this returns and how it differs from the other extract-like tools 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?

Explicitly names the alternative ('Complements `summary`: use it when the summary is too brief') and gives the selecting condition. The only omission is a when-not case (e.g. use `summary` when you need one sentence), which is easily inferred and does not undermine the 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?

No annotations were provided, so the description carries the full burden. It discloses that the output is a compact numbered list and notes that major articles can have 50KB+ of body text, giving useful context about the cost of alternatives. However, it does not state whether the tool is read-only (implied by 'Get') or mention any pagination, rate limits, or error cases. This is a moderate gap for a tool with zero annotation coverage.

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

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

Three sentences, each front-loaded with purpose: first defines what it gets, second explains why (use case), third maps the tool family. Zero waste, and the most important information (what it returns) is first.

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

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

Given the tool's simplicity (2 params, no output schema, no annotations) and the complexity of the sibling ecosystem, the description is complete: it covers purpose, usage context, return format, and pairing. 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 the schema already documents both 'lang' (with enum and default) and 'title' (with examples). The description does not add any parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate 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 and resource ('Get the table of contents (section headings) for a Wikipedia article') and immediately specifies the returned fields (section number, heading text, nesting level). It clearly distinguishes itself from siblings like article_extract and summary by naming them in the pairing sentence.

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 describes when to use this tool: 'before committing to the full body via article_extract' and 'for navigating long articles.' It names alternatives (article_extract, summary) and explains the workflow, making the selection condition 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?

No annotations are provided, so the description carries the burden. It usefully discloses the main-namespace filtering constraint ('talk/user/etc. don't pollute the result'), which is genuine behavioral context. However, it says nothing about result ordering, pagination beyond the limit param, or rate limits.

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 definition ('List incoming Wikipedia links to an article') before elaborating with examples and the namespace filter. Slightly verbose with the parenthetical examples, but each sentence adds routing or scope 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 no annotations and no output schema, the description needs to stand alone, and it covers purpose, the inverse relationship to `links`, use case, and result scoping. It omits return-format/ordering details, which is a minor gap for a simple list 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 lang, limit, and title are already documented in the schema. The description adds no parameter syntax or format detail beyond that, 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 (list) and resource (incoming Wikipedia links/backlinks), and explicitly names the sibling it inverts: 'Inverse of `links`'. An agent can distinguish it from external_links, links, and search without opening a schema.

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

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

Gives clear usage context ('graph-style discovery in the reverse direction — mapping an article's position in the encyclopedia network') and the inverse-relationship cue to `links`. It stops short of explicit when-not conditions or naming a preferred alternative for overlapping needs, so it lands just under 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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses that hidden/maintenance categories are filtered out, which is useful. However, it omits other behavioral details like whether results are ordered, pagination behavior, or whether it requires authentication.

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 two concise sentences, front-loaded with the core purpose and followed by a use-case and a filtering note. Every sentence earns its place without 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?

Given no output schema exists, the description adequately explains what the tool returns (categories) and the filtering behavior. It doesn't cover return format or pagination details, but overall provides sufficient context for an agent to invoke it correctly, though minor gaps remain.

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%, meaning all parameters are already documented in the schema with descriptions and defaults. The description adds no parameter-specific information beyond what the schema provides, so the baseline score 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?

States a specific verb (List) and resource (Wikipedia categories an article belongs to) with clear scope. The description distinguishes it from text-search siblings by describing it as taxonomy-based discovery, making the purpose immediately identifiable among tools like search or links.

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

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

Provides clear context for when to use the tool: 'taxonomy-based discovery — finding related topics that don't appear in text search.' This implicitly contrasts with search but doesn't name specific sibling tools or state explicit exclusions or prerequisites.

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

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

With no annotations, the description carries the behavioral disclosure burden. It includes several meaningful behaviors: it returns a 1-2 sentence extract and a thumbnail URL per entry, filters out subcategories and files by limiting to main namespace, and treats the 'Category:' prefix as optional. It does not cover pagination, ordering, or error behavior, but these are minor for a list-read 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 concise and well-structured. It front-loads the core action, then guides to the sibling tool, then details the output, then adds a non-obvious filtering behavior, and finishes with the direct pairing. No sentence is wasted, and the flow makes it easy to scan.

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

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

Given the absence of an output schema, the description supplies adequate shape information: each entry contains a title (implended by 'enumerate who's actually in it') plus an extract and thumbnail URL when available. It also shares the main-namespace filter and the prefix tolerance. Notationally, it could state ordering or pagination, but for a tool with 3 parameters and understandable semantics, this is sufficiently complete.

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 meaningful value: it clarifies that the category parameter accepts an optional prefix, and it explains the practical meaning of the extract and thumbnail responses that depend on the query. This goes beyond the schema's bare field 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 uses a specific verb and resource ('List Wikipedia articles filed under a category') and immediately differentiates itself from siblings by calling out `categories` and `search`. It even names a concrete example ('Machine learning researchers'), so an agent knows exactly what the tool does without opening the schema.

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

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

The description gives clear usage context: it is the reverse of `categories`, and it pairs with `categories` (to build the taxonomy) and `search` (to find an entry point). This implies when to choose this tool over the obvious alternatives, though it does not spell out an explicit 'when not to use' list beyond that alignment.

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

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

No annotations are provided, so the description carries the full burden. It adds useful behavioral context: the date is fixed to today's date in UTC, results are 'notable deaths', and the source is Wikipedia's On This Day feed. This clearly signals a read-only retrieval operation, though it does not describe return structure or pagination beyond that.

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

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

Two sentences with no filler: the first front-loads the core action and scope, the second adds use cases and sibling relationships. Every sentence earns its place.

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

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

For a simple two-parameter read-only feed tool, the description is nearly complete: it names the source, scope, timezone, use cases, and sibling tools. Since there is no output schema, a brief note on the returned shape would have made it fully complete, but this is a minor 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 description coverage is 100%, and the schema already fully documents 'lang' (with enum) and 'count' (default 5, max 10). The description adds no additional parameter-specific meaning, 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?

States a specific verb and resource ('Get notable deaths... from Wikipedia's On This Day feed') and distinguishes itself as the 'deaths-only companion to on_this_day' which returns events. An agent can immediately tell what this tool does and how it differs from its closest sibling.

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 gives concrete use cases ('in memoriam' content hooks, obituary-style social posts, newsletter intros) and names complementary siblings (on_this_day, featured_article) for building a full digest. It also clarifies the boundary: deaths only, versus events from on_this_day.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the fact is random and sourced from Wikipedia, which is useful. However, it lacks details on rate limits, authentication requirements, error handling, or whether the fact changes on each call.

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

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

A single, concise sentence that front-loads the core functionality and ends with a note on its practical use. No wasted words.

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

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

For a simple tool with one optional parameter (language), no output schema, and no annotations, the description covers the basics but omits behavioral details like rate limits or authentication. It is adequate but has clear gaps in behavioral context.

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 the 'lang' parameter fully. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb (Get) and resource (random 'Did You Know' style fact from Wikipedia). It distinguishes itself from the sibling 'random' by referencing the 'Did You Know' style, and from 'dino_fact' by citing Wikipedia.

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

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

The description implies usage via 'great for hooks and general trivia', but does not explicitly state when to use this tool versus alternatives like 'random' or 'dino_fact'. No exclusions or prerequisites are given.

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

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

With no annotations, the description carries the full burden. It usefully discloses the fallback behavior (a missing species silently returns a random dino) and that facts originate from Wikipedia, but it omits any note on rate limits, network dependence, or the shape of the returned 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 sentences, front-loaded with purpose and then split cleanly between the targeted and random modes. Minor redundancy: the random-dino case is stated twice (no-arguments and fallback).

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

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

For a two-parameter, annotation-free tool with no output schema, the description covers purpose, both invocation modes, and fallback behavior. The only meaningful gap is the absence of any indication of what the returned fact looks like.

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 the 'species' and 'lang' parameters are already documented (including the empty-string-for-random convention). The description restates the species semantics but does not explain the 'lang' enum's effect on output, 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?

The description uses a specific verb+resource combination ('Get a Did You Know style fact about dinosaurs or prehistoric life'), which is concrete and distinguishable from the generic sibling 'did_you_know' by domain. It stops short of explicitly naming the sibling to route away from, so it is clear but not maximally differentiating.

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 clearly states the two invocation modes: pass a species name for a targeted fact, or call with no arguments for a random dino. This is explicit context for how to use the tool, though it offers no exclusion guidance relative to sibling fact/article tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a safe read, and the scope ('off-wiki') is clarified, but nothing is said about error behavior for a missing article, pagination beyond the limit param, or return shape. Adequate but incomplete for a tool with zero annotation coverage.

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, then the trio framing, then use cases — a logical ordering. Slightly long with two enumerations of examples, but each sentence earns its place by adding differentiating context.

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

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

With no output schema and no annotations, the description still covers purpose, sibling positioning, and use cases, and the schema fully documents all three parameters. The only real gap is behavior on failure (nonexistent/invalid title) and any rate-limit or pagination nuance.

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 `lang`, `limit`, and `title` are already fully documented in the schema (including defaults and max). The description adds no format, syntax, or edge-case guidance for those parameters, 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 ('List') and resource ('external/off-wiki links from a Wikipedia article') and explicitly distinguishes itself from siblings `links` (internal outgoing) and `backlinks` (internal incoming). An agent can immediately tell which of the trio to call.

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 the scenario set (source verification, citation audits, primary-source discovery, fact-checking) and frames the tool as the 'outbound complement' within a trio, giving the agent a clear selection rationale versus `links` and `backlinks`. No competing tool overlaps are left ambiguous.

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

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

With no annotations and no output schema, the description carries the full burden and does disclose the returned payload ('full long-form extract plus thumbnail') and the qualitative nature of the content, which the structured fields do not. It stops short of describing error or edge behavior (e.g., what happens for a language with no featured article that day) or any rate/caching behavior, 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?

Front-loaded with the core action and resource, then the return value, then the sibling routing — a sensible order. The middle sentence ('reliably high-quality, surprising, in-depth content') is somewhat promotional and expendable, but the piece as a whole is tight and well under the point of bloat.

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 zero-required-param, no-output-schema tool, the description supplies the retrieval semantics, the returned content shape, and the sibling alternatives an agent needs. The only remaining gap is edge-case behavior such as missing featured articles per language, which is minor given the tool's simplicity.

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

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

Schema description coverage is 100% for the single `lang` parameter, including its enum and default, so the baseline is 3. The description adds no language-specific meaning beyond what the schema already documents.

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 ('Get today's Wikipedia Featured Article') and immediately defines the resource as the single article Wikipedia editors showcase that day, so the agent knows exactly what is being retrieved. It also names the two nearest siblings it must not be confused with, making it unambiguous 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?

Explicitly routes the agent: use picture_of_the_day for the daily image and on_this_day for historical events, with a stated rationale ('a strong daily source of hooks and deep dives') for when this tool is the right pick. Both the when-to-use and when-to-use-something-else conditions are given.

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

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

No annotations are supplied, so the description carries the disclosure burden, and it does reveal the return shape (300px thumbnail URL plus full-resolution original URL) and the no-image fallback behavior. It omits any note on rate limits, auth, or whether the URL is hotlink-safe, which keeps it short of a 5 for a zero-annotation tool.

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

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

Front-loaded with the core return contract, then the disambiguation from `summary`. The parenthetical use-case list ('cards, Telegram posts, slide decks, README hero images') is slightly padded and could be trimmed without losing meaning.

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

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

There is no output schema, so the description's explanation of the two returned URLs and the empty-image case does real work. Combined with a fully documented two-parameter schema, an agent has everything needed to call and interpret the result.

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

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

Schema description coverage is 100% and both params (lang enum, title) are fully documented in the schema, so the baseline of 3 applies. The description adds no syntax or format detail about `title` handling (e.g. underscores vs spaces) beyond the schema's own example.

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 ('Get just the lead image for a Wikipedia article') and immediately names what it returns. It explicitly differentiates itself from the sibling `summary`, which embeds the thumbnail inline, so an agent can route correctly 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?

Gives a concrete when-to-use condition ('when you want the article's image for embedding elsewhere ... without the surrounding summary text') with example scenarios, and names the alternative tool (`summary`) plus the reason to prefer this one. The contrast is explicit rather than inferred.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a genuinely useful trait not in the schema: results are filtered to main namespace so talk/user pages don't pollute output, and that this is the raw article network. However it says nothing about ordering, deduplication, or truncation behavior beyond the schema's limit.

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

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

Three sentences, front-loaded with the core action and scope. The middle illustrative sentence is a bit long but earns its place by grounding the use case; 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?

A simple read-only list tool with 3 fully documented params and no output schema; the description covers scope, the outgoing-vs-incoming distinction, and namespace filtering. Missing only minor operational detail like ordering.

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 lang, limit and title are already documented in the schema. The description repeats the 'Tyrannosaurus' title example but adds no syntax, format, or constraint meaning beyond what the schema provides. 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 and resource ('List outgoing Wikipedia links from an article'), and the word 'outgoing' implicitly separates it from the sibling 'backlinks'. An agent can tell what it retrieves 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 a clear use case with a concrete example ('given Tyrannosaurus, see which genera, paleontologists, formations...'), which orients the agent on when this is the right tool. It stops short of naming alternatives or stating exclusions, so it does not reach 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the output shape (structured markdown list with file title, type, caption, thumbnail URL), notes lead-media marking, identifies the underlying endpoint and that it is structured JSON with no HTML parsing, and states the limit default/max. Remaining gaps are minor (error behavior, truncation signaling beyond limit).

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 scope in the first clause, then layers output shape, the `image` comparison, and the `limit` semantics. A few sentences are dense but each earns its place; no restating of the tool name or boilerplate.

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 3-parameter, no-output-schema read tool, the description covers scope, output format, sibling routing, and a key parameter constraint — everything an agent needs to call it correctly. It could mention error/empty cases or auth requirements, but those are minor for a public Wikipedia endpoint.

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 does add useful runtime context for `limit` (default 25, max 100, clamping behavior) and confirms that `title` is the article being inventoried, but it doesn't add anything beyond the schema for `lang`.

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 (List) and resource (all media in a Wikipedia article) and immediately disambiguates scope ('not just the lead thumbnail'). It names the sibling `image` and draws the exact boundary between the two, so an agent can route correctly 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?

Explicitly names the alternative (`image` for the headline thumbnail) and the conditions that select this tool ('full inventory — gallery generation, fact-checking, slide decks, audits'). It also anticipates the case where the caller already has the lead media ('marked so callers can skip it when they already have it via `image`').

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

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

With no annotations, the description carries the burden and does add real behavioral context: it is a read-only listing operation, title anchoring reuses the article's own coordinates (no geocoding service), and results include distances. It omits auth, pagination, and error behavior, which keeps it from a 5.

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

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

Front-loaded with the core action and resource, then the two anchoring modes and the payoff. Most sentences earn their place, though 'Useful for travel research' is mild 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?

With 6 optional parameters, no annotations, and no output schema, the description supplies the missing glue: the anchoring modes and the return content. It never explicitly states that one of title or lat+lon is effectively required, which is the one remaining 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 baseline is 3, but the description adds meaning the schema does not: the title-vs-lat/lon mutual exclusivity and the fact that title anchoring avoids geocoding. That is genuine added semantics rather than restatement.

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 ('List Wikipedia articles geographically near a location') and immediately scopes it as location-based discovery. This clearly separates it from siblings like search, random, or featured_article without needing to name 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?

Explains the two anchoring modes and when to prefer each (title 'Use instead of lat/lon'), plus a concrete use case ('what's notable around here' questions). It lacks any explicit exclusion or named alternative sibling, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavior: the content is editorially curated (not algorithmic/search-driven) and bold-linked article titles are converted to Markdown. It does not mention caching, freshness, or failure behavior, but for a read-only fetch the disclosure is substantive.

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

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

Three sentences, front-loaded with the source and scope, then sibling differentiation, then output formatting. Every sentence carries information; the Markdown note could arguably sit in a return-value section but does earn its place given there is no output schema.

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

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

For a two-parameter, no-required-inputs read tool with no output schema, the description covers source, editorial nature, sibling alternatives, and output formatting (Markdown emphasis). Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so both lang and limit are already documented in the schema with defaults and the enum list. The description adds no format or semantic detail beyond that, so the baseline 3 is correct.

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

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

States a specific verb and resource (get current events from Wikipedia's Main Page 'In the news' section) and names the exact source and scope. It explicitly differentiates itself from featured_article and on_this_day by framing itself as 'the present tense,' so an agent can route 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?

It names the sibling tools (featured_article for long-form, on_this_day for historical) and gives the selecting condition ('news covers the present tense'). It stops short of an explicit when-not-to-use clause, but the routing rule is clear and actionable.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the data source, timezone basis (UTC), and the key behavioral quirk that results are a 'random sample' rather than a deterministic or complete list. It does not cover auth needs or rate limits, but for a public read-only feed tool that gap is minor.

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

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

Two tight sentences: the retrieval action and source come first, the return shape second, with no redundant restatement of the tool name. 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?

No output schema exists, so the description must describe returns — and it does ('year + description + Wikipedia link', random sample). Combined with a fully documented 2-param schema, 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% (both lang and count are documented with defaults and max), so the baseline is 3. The description adds the UTC date framing but nothing further about lang semantics or count behavior beyond what the schema already 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+resource ('Get historical events ... from Wikipedia's On This Day feed') and scopes it to today's date in UTC. It also names the sibling it pairs with (featured_article), making it distinguishable from random, did_you_know, and deaths_on_this_day.

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

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

The phrase 'great daily content hook alongside featured_article' gives an implied usage context, but there is no explicit when/when-not guidance and no mention of closer alternatives like deaths_on_this_day (which covers the same date concept) or random. Usage must be largely inferred.

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

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

No annotations are provided, so the description carries the burden and does well: it discloses the upstream source (Wikimedia's pageviews REST API), the default window semantics (last 7 days ending yesterday UTC), and the return shape. It omits error behavior, rate limits, and whether the title must match exactly, which mutes a perfect score.

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

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

Three sentences, each earning its place: purpose, situational use, source API/default window, and return format in that order. Front-loaded with the core verb and free of 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?

With no output schema, the description correctly compensates by naming the return contents (total, daily average, markdown table). Defaults, source, and return format are all covered for a straightforward read-only lookup, leaving nothing an agent needs 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 the schema itself documents title, start, end, and lang. The description's note about the default window duplicates the schema defaults rather than adding new syntax or format meaning, 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 ('Get daily view counts for a Wikipedia article') with scope ('over a date range'), which separates it from the sibling aggregate tools like top_reads and recent_changes. An agent can identify the resource type (per-article pageviews) without opening the schema.

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

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

The parenthetical '(popularity research, trending topics, historical interest)' gives clear situational context for when to reach for this tool. It stops short of naming an alternative or stating when-not to use it (e.g. vs. top_reads for site-wide rankings), so it doesn't reach the top band.

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

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

No annotations, so the description carries the full burden. It usefully discloses the return payload (preview + full-size URLs, photographer, license, description) and the default date behavior, but says nothing about error cases, permission/auth needs, rate limits, or what happens for dates with no picture.

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 dense sentences, front-loaded with the resource and what it returns, then the optional parameter and the sibling relationship. No filler or repetition; 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 correctly compensates by enumerating returned fields (URLs, photographer, license, description), and it explains the date default. The lang parameter's effect on output is left to the schema, a minor gap for an otherwise self-sufficient read 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 both parameters are already documented in the schema; baseline is 3. The description adds the YYYYMMDD format and UTC-default meaning for date, but does not mention the lang parameter or its enum values at all.

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 ('Get Wikimedia Commons' Picture of the Day') with the exact scope ('curated daily image from Wikipedia's featured feed'). It explicitly self-positions against a sibling by calling itself 'the visual counterpart to featured_article,' so an agent can distinguish it from 20+ other retrieval 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?

Gives clear context: default is today, and passing a date lets the agent 'browse past pictures,' framed as 'daily content hooks.' It names featured_article as the related tool, but offers no explicit when-not-to-use or selection rule beyond that pairing.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: selection is random from a curated (not open) corpus, and the output is a short quote with author attribution. It also flags a genuine gotcha — the `lang` parameter is accepted but non-English values silently fall back to English. It omits any mention of rate limits or caching, which keeps it below a 5.

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

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

Front-loaded with what the tool returns, then the related-tool pairing, then the language caveat, so the critical limitation is not buried. A clause of promotional framing ('great for daily content hooks, social posts, newsletter intros') is soft filler, but the sentences otherwise earn their place.

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

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

For a one-optional-parameter trivia tool with no output schema, the description covers purpose, the shape of the return value, the fallback behavior, and sibling relationships — enough to call it correctly. Nothing essential is missing; only marginal detail (rate limits, determinism) is absent.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds non-obvious meaning: the enum of ten language codes is effectively a no-op and returns English anyway. That directly corrects a misleading schema signal and is the single most useful thing an agent could know about this parameter.

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

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

States a specific verb and resource ('Get a random notable quote') plus the source pool (curated list of named authors). It also names the sibling tools it complements (did_you_know, dino_fact), so an agent can separate it from the generic 'random' tool 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 concrete usage contexts ('today's trivia' outputs, daily content hooks, social posts, newsletter intros) and lists the tools it pairs with. It stops short of any exclusion or routing rule — notably it never distinguishes itself from the sibling 'random' tool — so it is clear context but not full when/when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return shape ('title + summary + thumbnail') and language support, which is useful. However, it says nothing about the non-deterministic nature of the result, failure/empty-result behavior, rate limits, or whether results are cached, which matters for a randomness-based tool.

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

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

Front-loaded with the core action and scoping, followed by the return-shape comparison and use cases. Two sentences with little waste, though 'serendipitous discovery across the entire encyclopedia' and the icebreakers/trivia list lean slightly promotional.

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 zero-required-parameter, read-only tool with no output schema, the description does the important work of summarizing the return shape and language behavior. What remains missing is only minor behavioral detail (randomness, error cases), so it is nearly complete for its complexity.

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

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

Schema description coverage is 100% and the single `lang` parameter already documents itself with an enum and default. The description only adds 'supports other languages via `lang`,' which is marginal over the schema. 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?

States a specific verb (fetch) and resource (a random Wikipedia article summary) and explicitly contrasts itself with sibling `summary` by noting it returns the same title + summary + thumbnail shape 'but for a surprise topic.' An agent can distinguish this from `summary`, `featured_article`, and `did_you_know` 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 clear usage context: 'exploration, icebreakers, trivia, and content inspiration when there's no specific subject in mind,' and implicitly routes to `summary` by referencing it as the same-shaped-but-targeted alternative. The condition for choosing this tool is stated, but the inverse case ('use summary when you do have a subject') is only implied rather than spelled out.

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

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

With no annotations provided, the description carries the full burden and does notable work: it declares 'Read-only,' identifies the underlying feed and namespace scope, and enumerates the shape of each returned entry (kind, article link, byte delta, editor, timestamp, comment, diff link). It does not cover rate limits, latency/freshness guarantees, or pagination, which keeps it out of the top band.

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 source are front-loaded in the first sentence, followed by the filter semantics and the sibling comparison. It is somewhat long and includes mild promotional framing ('great for spotting breaking-news edits'), but each sentence conveys usable information rather than filler.

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

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

For a 3-param, zero-required, read-only feed tool with no output schema, the description supplies the missing return-value detail and the read-only safety profile. An agent has enough to call it correctly; only operational details like pagination or refresh behavior are absent.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine semantic meaning beyond the enum labels — 'edit' = text changes, 'new' = newly published articles, 'categorize' = category membership changes, 'log' = page moves, deletions, protections. It does not elaborate on `lang` or `limit`, which the schema already handles.

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 ('show the most recent changes to Wikipedia articles') and scopes it to the article namespace via the MediaWiki recentchanges feed. It also explicitly names the sibling it differs from ('Complements `revisions`... with the reverse angle'), so an agent can disambiguate 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?

Gives clear selection guidance: it explains that `revisions` is for the history of one article while this is the freshest edits everywhere, and it maps each `kind` value to a use case ('new' as a discovery feed, 'log' for moves/deletions/protections). It stops short of explicit when-not-to-use rules or prerequisites, but the alternative is named with the condition that selects it.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the exact return fields, the byte-size delta semantics, and that each revision links to its diff via Special:Diff/<revid>, implying a safe read. It omits pagination/limit behavior and rate-limit or auth context, which are minor for a read-only query.

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 purpose and return fields, then use cases and sibling contrast. Four sentences stay efficient, though the diff-link detail and use-case list 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?

No output schema exists, so the description must describe return values — and it does thoroughly (id, timestamp, editor, summary, delta, diff link). An agent gets enough to call it correctly; only pagination/limit semantics and ordering are left implicit.

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

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

Schema description coverage is 100%, so the schema already documents lang (with enum), limit (default and max), and title. The description adds nothing beyond the schema about parameter meaning or constraints, 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+resource ('Show an article's recent edit history') and enumerates exactly what it returns (revision id, timestamp, editor, edit summary, byte-size delta). It also explicitly distinguishes itself from the sibling `pageviews` by contrasting provenance vs. popularity.

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

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

Provides clear usage contexts (tracking article evolution, auditing edits, spotting current-event activity) and names `pageviews` as the complementary tool. However, it gives no when-not guidance and doesn't distinguish itself from plausible edit-oriented siblings like `recent_changes`, leaving the nearest alternative unaddressed.

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

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

With no annotations, the description carries the burden and does well: it discloses the return shape (ranked, numbered list with snippet and URL), the result cap (up to 20), and notable error-avoidance behavior ('Reports No results found for empty queries instead of erroring'). It doesn't cover cross-language behavior for `lang` or any rate/availability constraints, leaving a small gap.

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

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

Three sentences, front-loaded with the purpose, then return shape, then routing guidance. Every sentence earns its place and nothing is repeated from the schema beyond a brief parenthetical.

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

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

No output schema exists, so the description must explain return values — and it does, describing the ranked numbered list, snippets, and URLs. Combined with the routing guidance to downstream tools, 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 the schema already documents `query`, `lang`, and `limit`. The description only echoes the `limit` cap (already in the schema as 'max 20'), adding no new semantic detail. Baseline 3 is appropriate 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 and resource ('Search Wikipedia for articles matching a query') and explicitly positions itself as 'the entry point when you don't know the exact article title,' which distinguishes it from siblings like `summary` and `article_extract` that require a known title.

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 when-to-use ('when you don't know the exact article title') and names the downstream alternatives with their distinct purposes: `summary` for the gist, `article_extract` for full text, `links` to explore outward. The routing logic is fully spelled out.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses the return content (summary plus optional lead thumbnail) and the exact-title precondition, which is the key failure mode for this tool. It does not mention error behavior when a title doesn't exist, but the essential traits are covered.

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

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

Three sentences, each earning its place: capability, usage hint with examples, then sibling routing. The core capability is front-loaded and nothing is padded.

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

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

No output schema exists, so the description must convey returns — and it does (summary plus thumbnail when one exists). Combined with explicit sibling routing and full schema coverage, an agent has everything needed to select and 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 both `title` and `lang` are already documented, including the enum values and default. The description only reinforces the exact-title semantics already in the schema, so baseline 3 applies.

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

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

Specific verb (Get) plus resource (concise summary of a Wikipedia article) with scope stated: by exact title, plus lead thumbnail when present. It clearly distinguishes itself from article_extract and article_sections, so an agent can pick it 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?

Explicit routing: exact title required, and if the title is unknown the agent is told to use `search` first. It also names the alternatives for adjacent needs (article_extract for full text, article_sections for outline), covering when-not-to-use.

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

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

No annotations are provided, so the description carries the full burden and does a good job: it discloses the data source (Wikimedia top-pageviews, all-access, daily), the default date rationale (today's data not finalized), and the namespace filtering that removes non-article noise. It does not cover rate limits, auth, or response shape, but the substantive behavior is well documented.

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 purpose, followed by source, default-date caveat, filtering note, and sibling comparison. Slightly long, but each sentence earns its place; only the endpoint/routing sentence could be trimmed.

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

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

For a no-annotation, no-output-schema tool with three well-documented params, the description is complete enough to invoke correctly: it covers source, date semantics, filtering, and sibling differentiation. Minor gaps (return shape, result ordering) remain, but nothing 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 coverage is 100%, so the schema already documents date, lang, and limit. The description reinforces the date default (yesterday UTC) and explains the namespace filtering behavior, but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate 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 opens with a precise verb+resource: 'Get the most-read articles on Wikipedia for a given date,' and then names the underlying endpoint. It clearly distinguishes top_reads (aggregate popularity) from the sibling pageviews (per-article trending), so an agent can route between them 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 explicitly frames when to use this tool versus pageviews ('what is everyone reading right now' vs 'how is this specific article trending'), giving the agent a decision rule. It also notes the default date behavior and why finalized data matters.

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

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

With no annotations, the description carries the disclosure burden and does a reasonable job: it reveals the result shape (other-language editions/titles), discloses the `limit` clamp with default and max, and warns that popular articles exceed 100 languages. It does not explicitly state that the operation is read-only or describe pagination/truncation behavior beyond the clamp, so a 4 rather than a 5.

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

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

The core definition and the sibling differentiation are front-loaded, and most sentences earn their place. The use-case list ('translation research, cross-language content sourcing, language-coverage analysis') is somewhat enumerative and could be trimmed, but the description is otherwise tight.

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

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

There is no output schema, so the description must convey return contents, and it does so at a useful level (other-language titles, e.g. de/fr/es/ja/zh). Combined with the coverage of all three parameters, an agent has enough to call it correctly; explicit read-only/pagination notes are the only meaningful omission.

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 practical meaning: it explains why `limit` exists ('popular articles can have 100+ language versions') and frames `lang` as the source-language selector that other tools expose one-way. The `limit` default/max is largely a restatement of the schema, so the added value is real but modest.

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 ('List all language versions of a Wikipedia article (langlinks)') and grounds it with a concrete example ('Tyrannosaurus' -> de/fr/es/ja/zh). It also differentiates itself from siblings by contrasting with the one-way `lang` parameter used elsewhere, so an agent can distinguish it 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?

It states clearly when this tool is the right choice: when the caller needs the article's full language coverage to pick a target language to fetch next, and lists concrete scenarios (translation research, cross-language sourcing, coverage analysis). It does not give explicit when-not-to-use exclusions or route to a specific alternative tool, keeping it just 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.