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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower. The description adds real behavioral context beyond them: photo/video items often have empty bodies, and long stories are chunked so parts > 1 requires repeat calls.

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 behavior, then the coverage caveat and the pagination rule. No repetition of schema or annotation content.

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 adequately (full body text plus a `parts` count driving re-calls), and covers the photo/video edge case. It stops short of naming other returned fields such as title or date, which would be a minor addition.

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 the operational meaning of `part` — the loop 'call again with part=2, 3, ...' when parts > 1 — which the schema alone does not convey. It also reinforces that the url should come from the sibling listing tools.

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

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

Names a specific verb and resource ('Fetch one article page and return its full body text') and immediately qualifies the scope with pagination behavior, which cleanly separates it from the discovery siblings nw_search / nw_latest / nw_latest_all.

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?

States that it 'works for every source' and that the URL should come from the discovery tools, and gives an explicit follow-up rule for parts > 1. It does not spell out an exclusion against alternatives, but the position in the workflow (follow-up to search/latest) is clear.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive behavior, so the safety profile is free. The description still adds real value by disclosing the item shape and the non-obvious `stale: true` flag semantics (feed newest story over 3 days old), which cannot be inferred from structured fields.

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

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

Front-loaded with the core purpose, then return fields, then the stale caveat, then routing hints — a sensible order with no filler. The second paragraph is slightly dense but 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 compensates by enumerating the returned fields and the timestamp format (UTC ISO). Combined with the stale-flag explanation and the source-slug routing, nothing an agent needs to call or interpret this tool 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 all three parameters are already documented, including the 1-15 limit range and category slug source. The description adds only a redundant pointer to nw_list_sources for slugs and says nothing extra about `limit` behavior.

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 ('Return the newest headlines') plus the scope ('one news source, optionally of one category'), which implicitly contrasts with the sibling nw_latest_all and with nw_search. An agent can tell what this returns 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 routes the agent: nw_list_sources for category slugs, nw_search for cross-source topic lookup. The 'one news source' scope implies when to prefer nw_latest_all, but that alternative is never named and no when-not condition 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 readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely new behavior: results are merged and time-sorted, and sources that failed or lack the category surface under `errors`, which tells the agent to expect partial success rather than an exception. It omits item shape and any pagination/rate-limit notes.

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 behavior, then usage, then failure handling. 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?

For a 3-param, all-optional read tool with no output schema, the definition covers purpose, narrowing, and the `errors` key. It would be stronger if it sketched the returned item fields (headline, source, timestamp), since no output schema exists to convey them.

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

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

Schema description coverage is 100%, so all three parameters are already documented including defaults and the per-source 1-2 cap. The description only reinforces the category notion ('common category slug such as economy or sports') and the empty-means-all semantics already in the schema, adding little beyond it and saying nothing about per_source's effect on the merged list.

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 (return newest headlines), plus the scope (from every source or the chosen ones, merged and sorted by time). It explicitly carves out nw_tech_news, but leaves the distinction from the closely named sibling nw_latest implicit rather than stated.

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

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

Gives a clear when-to-use (general news overview, narrow with a category slug) and an explicit when-not with the replacement tool (technology questions -> nw_tech_news). It does not address when to prefer nw_latest or nw_search instead, so one sibling decision 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 readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered; the description adds value beyond that by enumerating the group vocabulary (news = Iranian general news, tech, sports) and disclosing that ids from here feed the `sources` filter on other tools. It stops short of covering result size or ordering, but nothing is contradicted.

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

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

Front-loaded with the purpose, then the group vocabulary, then the next-step routing, in three short blocks with no filler. The backticked fragments and compressed phrasing ('Pass chosen ids as `sources` to nw_search / nw_latest_all to filter by group') make it slightly telegraphic rather than flowing, but nothing is wasted.

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

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

For a zero-param catalog tool with no output schema, this covers what is returned (groups and category slugs) and how to consume it downstream, which is the critical gap for param-less discovery tools. Minor residual ambiguity remains about the exact shape of an id versus a slug, but an agent has enough 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?

Zero parameters, so the baseline is 4. The description still earns its keep by explaining how this tool's output maps onto the `sources` parameter of nw_search/nw_latest_all, which the empty schema cannot 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 ('List the news sources') and immediately names the returned payload ('group and category slugs'). It also positions itself relative to siblings by declaring 'call this first' to obtain valid source/category values, so an agent can distinguish it from nw_search or nw_latest without opening a schema.

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

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

Gives explicit sequencing ('call this first'), names the concrete alternatives to use next (nw_latest, nw_search, nw_latest_all), and adds a disambiguation rule ('for technology questions use nw_tech_news'). This is exactly the when/when-not/alternative guidance the dimension asks for.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description goes well beyond them: it discloses that matching is client-side over in-memory feeds, that the effective window is roughly the last 10-300 stories rather than an archive, that results are newest first, and that failed or uncategorized sources surface under `errors`. Those are the exact traits an agent needs to interpret partial or empty results correctly.

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 with zero filler; the operational constraint (feeds, not archive) is front-loaded before the sibling redirect. The parentheticals carry real information rather than restating 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 usefully explains the `errors` field and result ordering, which is more than most search tools offer. It still omits what a returned item contains (title, source, link, timestamp), which an agent would need to reason about the response shape without an output schema.

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

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

Schema description coverage is 100%, so the schema already documents query matching, the 1-15 limit cap, source ids, and category slugs taken from nw_list_sources. The description's 'keyword' phrasing adds only slight reinforcement and no new syntax, format, or edge-case detail, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Search recent headlines of several sources for a keyword') along with the scope of the corpus (current feeds only, newest first). It explicitly distinguishes itself from the sibling nw_tech_news, so an agent can route 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?

Names one alternative and the condition that selects it ('For technology topics use nw_tech_news instead'), and clarifies the archive limitation so an agent knows when the tool is inappropriate. It does not address how to choose between this and siblings like nw_latest or nw_latest_all, leaving part of the routing problem 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 establish readOnly/idempotent/non-destructive, and the description adds real operational context beyond them: Digiato is paged several feed pages deep so limit up to 30 is meaningful, topic scans the latest 50 Digiato stories (300 for Zoomit), and `scanned` reports how many stories were searched. It also discloses the returned item shape (title, url, UTC ISO published, ≤300-char summary, categories, author), which no output schema provides.

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

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

Front-loaded with purpose and the routing rule, then operational detail, then the next step — a sensible order. Slightly dense: the parenthetical domain list and the item-field enumeration could be trimmed, though both carry 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 supplies the return-field contract and the meaning of `scanned`/`count`. Combined with defaults, per-source paging depths, empty-result fallbacks, and the follow-up tool, an agent has everything needed to call it and interpret results.

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

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

With 100% schema coverage the baseline is 3, and the description earns above that by explaining cross-parameter behavior the schema cannot: why `limit` up to 30 is honored, what corpus `topic` is scanned against per source, and that `source` defaults to the richest feed. It stops short of restating per-parameter syntax, which is already well documented in the schema.

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

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

Names a specific verb and resource ('Return the newest technology news') and enumerates the covered domains (phones, laptops, AI, crypto, security, games). It also explicitly positions itself against siblings ('Use this first ... instead of nw_search or nw_latest_all'), so the agent can distinguish it 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 states the selection rule ('use this first for any technology question') and names the two tools it supersedes. It also gives a recovery path when results are thin ('if count is 0 or low, try a shorter or more general topic, or source="both"') and a handoff to nw_article for full text.

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