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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds relevance ranking and enumerates the returned fields (id/link, title, date, authors, abstract), which is valuable since there is no output schema. It doesn't mention rate limits or the 20-result cap, keeping it short of 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?

Three sentences, zero padding, with purpose first and the alternative and return values following in order of decision relevance.

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

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

For a two-parameter read-only search with full schema coverage and good annotations, the description covers purpose, routing and return shape. Only minor gaps remain (pagination/limits, dedup or sorting options) that an agent would rarely need before calling.

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% (query example and limit 1-20 range are documented), so the baseline is 3. The description adds that the query matches across title, abstract and authors, which is useful semantic detail but modest beyond the schema.

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

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

States a specific verb ("Search") and resource ("arXiv research papers") plus the searched fields (title, abstract, authors) and ranking behavior. It is immediately distinguishable from wikipedia_search and other siblings.

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

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

Explicitly routes the agent: "Use it for academic preprints; use wikipedia_search for general background." That names an alternative and the condition selecting it, though other search siblings (github_search_repos, hackernews_search) are not contrasted.

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

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

Annotations only declare readOnly and openWorld, so the description usefully adds that rates are ECB reference rates updated once per working day - important context that the data may be stale within a day. It also discloses the return shape (base, date, rates map). Missing only exotics like rate limits or error behavior, which matters less for an open public API.

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

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

Three short sentences, front-loaded with the domain tag and the core action; the omission rule and return example are each one clause. Nothing waste-like or redundant with 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?

No output schema exists, but the description compensates by sketching the response object (base, date, rates, rates.CNY). For a two-optional-parameter read tool this is nearly complete; only auth/error behavior is unstated.

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

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

Schema coverage is 100%, so both parameters are already documented in structured form. The description only adds the default-full-set behavior for omitting symbols and the ~30 currency count, which is a modest increment over the schema rather than new semantics for base.

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

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

Names a specific verb and resource ("Get the latest European Central Bank reference exchange rates") plus the source and update cadence. No sibling tool overlaps with currency rates, so no differentiation is needed, and the tag prefix makes its domain obvious at a glance.

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 operational guidance: base currency selects the pivot, and "Omit symbols to get all ~30 currencies" tells the agent exactly how to get the full set. It stops short of when-not-to-use or alternative-source guidance, but the sibling list contains no competing tool.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description isn't carrying the safety burden. It adds real value beyond them: results are a ranked candidate list (best match first) with specific fields, which is exactly the ambiguity an agent needs to know about. It omits failure behavior (no matches) and any rate-limit notes, keeping it short of 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?

Three sentences, each doing distinct work: purpose, sequencing dependency, return shape. The most decision-relevant fact (this feeds weather_forecast) is front-loaded in sentence two with zero 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 steps in to list returned fields, which is the main gap it needed to close for a 3-param read tool. The only missing piece is what happens on a zero-match result, a minor omission for a geocoder.

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

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

Schema coverage is 100%, so all three parameters are already documented with defaults and bounds. The description restates the effect of `limit` ("up to `limit` candidates are returned") but adds no format or syntax detail beyond the schema. Baseline 3 is appropriate.

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

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

States a concrete verb+resource transformation: turning a city or place name into coordinates. It also distinguishes itself from weather_forecast by naming the upstream role it plays, so an agent can identify it without reading 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?

"Use this before weather_forecast, which needs latitude/longitude" gives an explicit ordering constraint and names the dependent sibling. The agent knows both when to call it and why, rather than having to infer from sibling names.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real context beyond them: the tool fails on nonexistent or private repos, and it enumerates exactly which metadata fields come back. That failure-mode disclosure is the kind of behavior an agent can't infer from the annotations.

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

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

Two compact sentences: capability plus return fields first, then the routing rule, then the error condition. No filler, and every clause carries actionable 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 compensates by listing the returned fields, and it covers the main failure case. A slightly richer statement of scope (public-only, no auth/rate-limit implications given openWorldHint) would fully close the gap, but nothing essential is missing for correct invocation.

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

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

Schema coverage is 100% and both params carry their own descriptions with examples, so the schema does the heavy lifting. The description only restates "owner and name" at a high level without adding format or edge-case detail (e.g., case sensitivity, URL vs. name), which is the expected 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 and resource ("Get metadata for one public repository"), specifies the keying (owner + name), and enumerates the returned fields. It is clearly distinct from github_search_repos, which is named and framed as the keyword-based alternative.

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

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

Explicitly states when to prefer the sibling: "Use github_search_repos first if you only have keywords." It also gives a usability precondition by implying you must already know owner and repo, so an agent can route correctly without reading either schema.

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

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

Goes well beyond the readOnly/openWorld annotations: discloses qualifier syntax support, the exact returned fields (full_name, description, stars, language, url, updated_at), the limit bound, and a rate-limit caveat for unauthenticated calls. This is exactly the operational context annotations cannot carry.

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

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

Four short sentences, front-loaded with purpose and routing, then capabilities, then return shape, then the rate-limit caveat. Every sentence carries distinct information with no repetition of the name or title.

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 fields. Combined with routing guidance and the rate-limit warning, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an uplift by explaining that the query string accepts GitHub search qualifiers and giving a concrete example with stars:>100, which the schema only hints at.

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 ("Find public GitHub repositories matching a query") and immediately contrasts with the sibling github_repo. An agent can distinguish it from every other sibling without reading 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?

Explicitly gives the when-to-use rule ("when you don't know the exact repo") and names the alternative (github_repo) with the condition that selects it. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and data-source profile is covered. The description adds the ranking guarantee and enumerates the returned fields, which is useful. It does not mention rate limits, whether results are cached, or freshness of 'currently', so it adds only moderate context beyond the structured fields.

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

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

Two sentences, front-loaded with the primary action, then the routing rule, then the return fields. Every clause earns its place with 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 zero-required-parameter list tool needs little more: the description covers scope, ranking, the sibling alternative, and the return shape, while the schema handles the one optional input. 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% for the single 'limit' parameter (1-30, default 10), so the schema fully documents the input. The description never mentions the limit, so it adds no meaning 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 ('List the stories currently on the Hacker News front page') with the ranking semantics ('ranked as on the site'), and explicitly contrasts itself with hackernews_search. An agent can distinguish it from the search sibling 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 both sides of the routing decision: 'Use this to see what is trending now' versus 'use hackernews_search to find stories on a topic.' The alternative is named and the selecting condition is explicit, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds non-obvious context beyond that: comments are excluded from the index and results are relevance-ranked, and it enumerates the returned fields. It does not mention rate limits or result-cap behavior, so it stops short of 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?

Two sentences, both earning their place: scope and ranking first, then routing to the sibling, then return shape. No filler or repetition of the title.

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

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

For a two-parameter read-only search with no output schema, the description supplies everything needed to call it correctly and even describes the return fields. Nothing material is missing.

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

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

Schema coverage is 100%, so both the query string and the 1-30 limit are already documented in structured fields. The description only adds the relevance-ranking semantics and confirms matching is against titles and text; 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 (full-text search of Hacker News stories) plus two distinguishing scopes: stories not comments, and ranked by relevance. An agent can separate it from hackernews_front_page 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 gives the use case ('find discussions about a product, project or topic') and names the alternative with its condition ('use hackernews_front_page for what is trending now'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds two pieces of non-obvious behavior beyond the annotations: it enumerates the returned fields (useful since there is no output schema) and discloses the error case when the package does not exist. It doesn't mention rate limits or whether scoped/private packages are supported.

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

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

Three short sentences, front-loaded with what is returned, then the alternative, then the failure mode. No filler and no restatement of the tool name.

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

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

With no output schema, the description compensates by naming the returned fields and the error condition, which is enough for an agent to call this correctly. Minor gap: it doesn't clarify whether version history or dist-tags are included, but nothing essential 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% and the single 'name' parameter already documents its own format with examples ('express', '@types/node'). The description adds no syntax, casing, or scoped-package guidance beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (Get) and resource (npm package) and enumerates exactly which fields come back: latest version, description, license, homepage. It also explicitly names the sibling it is not (npmstats_downloads), so an agent can route between the two 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 explicit routing guidance: 'For download counts use npmstats_downloads instead,' which resolves the most plausible sibling confusion in this tool set. It does not cover other alternatives (e.g. github_repo for source metadata), but for a single-purpose registry lookup the main exclusion is handled.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds the important behavioral constraint that the window is fixed at 7 days (no range parameter) and previews the returned fields. It doesn't mention caching, rate limits, or how missing packages are reported.

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

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

Three short sentences, front-loaded with the core action and window, followed by the disambiguation and the return shape. 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?

With no output schema, the description correctly describes the return fields (package, downloads, start and end dates), and the single required parameter is covered by the schema. Nothing an agent needs in order to call it and interpret results is missing.

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

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

The single `name` parameter is fully documented in the schema, including scoped-package examples like '@types/node'. The description adds nothing beyond 'npm package' — which is adequate but purely baseline given 100% schema coverage.

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 download counts) and resource (npm package) with a scoped window (last 7 days) and frames the metric's meaning as a popularity signal. It also names the sibling npm_package and what that one is for, so an agent can distinguish the two 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?

Explicitly routes version/license lookups to npm_package, giving a clear alternative with the condition that selects it. It lacks guidance on when download counts are or aren't the right popularity signal versus other sources, but the core alternative is stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description's added value is the failure modes it discloses: empty results behind logins/paywalls and truncation on long pages. That is real behavioral context beyond the structured fields, though it omits rate limits or JS-rendering 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?

Three compact sentences: purpose first, routing second, limitations last. No filler and every sentence carries distinct information.

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

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

For a one-parameter read tool, the description covers intent, return format (Markdown), sibling routing, and known failure modes, while annotations carry the safety profile. Nothing needed to invoke it correctly is missing despite there being 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 coverage is 100% and the single 'url' parameter is fully documented in the schema, including the http(s):// pattern. The description's phrase 'any public web page' adds only marginal 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 (Fetch), resource (any public web page), and the return transformation (main content as Markdown, nav/ads stripped). This makes it clearly distinct from every sibling, which are all domain-specific lookup 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?

Explicitly frames itself as a fallback and names the alternatives ('prefer wikipedia_summary, github_repo etc. when they fit'), which directly routes the agent among siblings. The when-to-use condition is stated, not implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: the returned fields (temperature °C, humidity, wind km/h, WMO code, per-day max/min and precipitation mm) and that values are in the location's local timezone. It doesn't discuss rate limits or error behavior for invalid coordinates, keeping it short of 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?

Three tight sentences: purpose first, routing prerequisite second, return shape third. No filler and no repetition of schema bounds.

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 by naming the metric set, units, and timezone behavior. Combined with full schema coverage and read-only annotations, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so latitude, longitude, and days are fully documented with ranges and defaults. The description reinforces the coordinate-based input and the units of the returned values but adds no syntax or format detail about the parameters themselves, 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 current conditions and a daily forecast') plus the input mode ('a location given by coordinates'). It also implicitly excludes the reverse geocoding case by pointing at geocode_search, so an agent can separate it from siblings 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?

Explicitly names the prerequisite case: if you only have a place name, call geocode_search first. That is a concrete when-to-use/when-to-route-elsewhere instruction, exactly the kind of routing guidance an agent needs.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower; the description still adds what comes back ('titles, short descriptions and excerpts') and the ordering ('best match first'), which matters for interpreting results. It stops short of mentioning rate limits, result cap, or pagination behavior, keeping 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?

Three short sentences, front-loaded with what the tool is, then the routing rule, then the return shape. No sentence is redundant and nothing important is 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 usefully summarizes the return values and their ordering, and it flags the English-only scope. It is nearly complete for a simple two-parameter search; only an explicit note on the default/limit behavior would close the 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 description coverage is 100%, so both parameters (query, limit with default/max) are already documented in structured form. The description adds no extra syntax guidance on query phrasing or result limits, so this sits at the baseline.

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

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

States a specific verb (full-text search) and resource (English Wikipedia), plus its scope and language. It is immediately distinguishable from sibling wikipedia_summary, which it explicitly names as the follow-up step.

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 when-to-use rule ('find the right article title') and names the alternative/next step ('then call wikipedia_summary with it'). An agent knows exactly when this tool is the right entry point versus the article-fetch sibling.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely useful context: redirects are followed, only English Wikipedia is served, and only the lead extract is returned rather than the full article. It does not mention failure behavior for nonexistent/ambiguous titles, keeping it short of 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?

A single tight sentence pair: the capability and its scope come first, the fallback routing second. Every clause carries information; no filler.

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

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

For a one-parameter read tool with no output schema, the description supplies the return fields (title, short description, lead extract, url) and the language scope — everything needed to call it correctly and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by clarifying that the title must be exact and that redirects are silently resolved — semantics the schema's 'exact article title' example does not convey.

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 lead summary of an English Wikipedia article') scoped by exact title. It is clearly distinguished from the sibling wikipedia_search, which handles lookup rather than retrieval.

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 to the alternative: 'If you are unsure of the title, use wikipedia_search first.' The condition that selects the alternative is spelled out, leaving nothing to inference.

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