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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is low, and the description still adds useful behavior: long stories are split into parts and how to continue, plus the caveat that photo/video items may have no body. No permission, rate-limit, or failure-mode detail is given, but nothing contradicts the annotations.

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

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

Three short sentences, front-loaded with purpose before caveats and the pagination instruction. Every sentence carries distinct information 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?

There is no output schema, so the description must describe the return surface; it does explain the body text and the `parts` count, which is the field the caller must act on. It omits other likely metadata (title, author, date, source), leaving a small gap for an article-detail 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% and the schema already documents both url and part (6000-character chunks), so the baseline would be 3. The description goes beyond it by explaining the retrieval loop ('parts > 1 means call again with part=2, 3...'), which tells the agent when and how to increment part.

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

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

States a specific verb and resource: 'Fetch one article page and return its full body text', including the singular scope ('one article page') and the part-splitting behavior. It is clearly the detail-fetch counterpart to the list tools, but it never names nw_latest / nw_search as the sources of the url, so sibling routing is left to 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 real operating context: works for every source, and photo/video items often return no body text (a soft when-not). It also states the follow-up rule for pagination ('parts > 1 means call again with part=2, 3...'). It stops short of explicitly telling the agent to use nw_latest/nw_search to obtain the url first.

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 (readOnly, idempotent, non-destructive, open world), so the description earns credit for adding return-field semantics (title, url, published as UTC ISO, plain-text summary, categories) and the non-obvious 'stale: true' contract meaning the feed's newest story is over 3 days old. It stops short of covering result-count edge cases or rate 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?

Front-loads the purpose in the first sentence, then a compact item-shape explanation, then routing guidance — all sentences carry weight. The repeated mention of nw_list_sources is minor 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?

With no output schema, the description compensates by describing the returned fields and the stale flag, and annotations cover the safety profile. Ordering and limit bounds live in the schema, so an agent has essentially everything needed; only empty-result or pagination behavior is unaddressed.

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 each parameter (limit, source, category) is already fully documented in the schema, including defaults, ranges and examples. The description only re-points to nw_list_sources for slugs, adding no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('return the newest headlines of one news source, optionally of one category') and pins the scope to a single source, which cleanly separates it from the all-sources sibling nw_latest_all and from cross-source topic lookup.

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 alternatives: nw_list_sources for category slugs and nw_search for topic-across-sources searches. It does not name nw_latest_all or nw_article, so the routing is clear on context but not exhaustive over all four siblings.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: results are merged and time-sorted, and failed sources or sources lacking the category surface under an `errors` key.

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 return behavior, then usage, then the error caveat. No filler or repetition of 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?

With no output schema, the description usefully discloses the merge/sort behavior and the `errors` field. It could say more about ordering ties or how many total items result, but for a read-only aggregation tool it is essentially 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%, with defaults, ranges and examples already documented for all three parameters, so the baseline is 3. The description only restates the source selection and illustrates category slugs, adding little 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 and resource: returns newest headlines from every source, merged and sorted by time. The 'every source (or the chosen ones)' scope implicitly separates it from nw_latest, but no sibling is named explicitly.

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

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

Gives a clear use context ('for a news overview') and tells the agent how to narrow with a category slug. It stops short of naming alternatives (nw_latest, nw_search) or stating when not to use it.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the fixed set of six sources and the fact that this call is the lookup step for valid downstream parameter values. It doesn't disclose the actual category slugs it promises, which keeps 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?

Two tight sentences: the purpose and usage rule come first, the enumeration second, the routing last. 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?

For a zero-param, no-output-schema tool, the description supplies the enumeration an agent needs to act without a trial call. The only gap is that it advertises category slugs but never shows them, forcing the agent to invoke the tool to learn 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?

Zero parameters, so the baseline is 4 and the schema has nothing to document. The description nonetheless adds parameter-relevant meaning by naming the values that feed sibling tools' `source` and `category` fields, though it stops short of listing the category slugs themselves.

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 six news sources and their category slugs') and even enumerates the six sources by name, so the agent knows exactly what comes back. It distinguishes itself from siblings by framing itself as the prerequisite discovery call for valid `source` and `category` values.

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

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

Explicitly says 'call this first' and gives the downstream path ('Next: nw_latest, nw_search or nw_latest_all'), so both when-to-use and which alternative follows are spelled out. 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely new behavior: searching is done client-side, coverage is roughly the last 10-300 stories per feed, and failed or category-less sources surface under `errors`. It stops short of explaining rate limits, per-source failures' effect on result counts, or result ordering beyond 'newest first'.

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 the important 'not an archive' caveat before the `errors` note. No filler; nearly every clause carries information.

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

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

No output schema exists, so the description usefully discloses one return-side detail (the `errors` list) and the freshness bounds that determine result completeness. Minor gaps remain (pagination, max results across sources, what happens when limit exceeds available items) but nothing critical for calling 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 baselines of 3 apply. The description reinforces scope for `sources` and `category` (the feeds vs main latest feed distinction) but adds no syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Search recent headlines of several sources for a keyword') and immediately bounds the scope as client-side over current feeds, newest first. It is clear what the tool does, though it never names nw_latest or nw_latest_all, which look like the nearest alternatives, so sibling differentiation is left to inference.

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 clause 'Only the items currently in each feed ... are searched, not an archive' is a useful scope boundary that tells the agent when results will be thin, and the category param points at nw_list_sources. However, there is no explicit guidance on when to pick this over nw_latest or nw_latest_all, so routing remains implied.

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