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

Beyond the readOnlyHint/openWorldHint annotations, it discloses non-obvious behavior: results come back grouped by outlet, and active outlets with no matching item are returned too, with the caveat that 'silence' may simply reflect keyword/language mismatch. It also warns that key terms must be supplied in every relevant language, which directly shapes correct invocation.

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 purpose and return behavior, then the matching rules and Args, which is a sensible ordering. The 'When answering...' paragraph is useful but is answer-style guidance rather than tool-invocation guidance, so it is slightly off-target and lengthens the description.

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 must explain what comes back, and it does: matching items grouped by outlet plus outlets with no matches. Combined with the parameter documentation and language caveat, an agent has everything needed to call it and interpret the result.

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

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

Schema description coverage is 0%, so the description carries the full burden and does: topic is documented with AND ('spaces') and OR ('|') semantics plus a multi-language example, days is the look-back window with default 7, and per_source is capped at 10 with default 3. Every parameter gains meaning not present in the bare 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 ('compare how different outlets/countries covered one story') and immediately frames the use case as framing comparison with a concrete example query. It also distinguishes itself from the sibling news_by_topic by noting it uses the same matching but groups results per outlet, so an agent can tell the two apart 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?

Provides a clear usage scenario and an example phrasing, plus points to news_by_topic as the related matcher, which implicitly routes single-topic searches elsewhere. It does not explicitly state when not to use this tool (e.g., when no cross-outlet comparison is wanted), so it falls short of a full when/when-not/alternatives statement.

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 read-only, non-open-world profile, and the description layers on genuinely useful behavior: filters combine with AND, defaults (24h/15 items), and caps (~336h, max 50). It does not describe result ordering beyond 'newest first' or pagination, but that is minor against the 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 purpose followed by a clean per-argument list; every line adds information. Slightly long, but nothing is padding, so it stays efficient for a six-parameter tool.

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 six-parameter, no-output-schema read tool, the description documents selection, filtering semantics, and limits thoroughly. Only the shape of returned items is unaddressed, which is acceptable given the read-only annotations.

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 0%, so the description carries the full burden and does so: every one of the six parameters gets meaning, format (ISO 639-1, ISO 3166 alpha-2), examples, defaults, and range for hours/n. This is exactly what a low-coverage schema requires.

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 resource and ordering ('Most recent headlines, newest first') plus its scope. It reads clearly as a general latest-news feed, distinguishable from news_by_topic, but it never names a sibling or explains the split between 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?

Concrete natural-language triggers ('what's the news', 'latest from Ecuador', 'what does DW say today', 'tech news') give an agent a clear sense of when to reach for it, and it points at sources() for feed ids. It lacks any when-not or explicit alternative-selection rules.

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

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

Annotations only cover readOnly and openWorld, so the description carries the real behavioral load and does it well: substring matching semantics, case/accent insensitivity, per-language corpus limits, AND/OR operator behavior, and hard caps (days ~14, n 50). It stops short of describing result shape or what 'summary' fields contain.

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 ordering, then matching rules, then per-arg notes. The cross-language examples are the most expensive part but they earn their place by teaching non-obvious query construction; a touch of redundancy in restating operators.

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 thin annotations, the description supplies the matching model, language limitation, and parameter caps an agent needs to call it correctly. The only missing piece is any indication of what a returned item looks like, which matters for chaining into downstream tools.

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 0%, so the description must do all the work, and it does: query documents space=AND and '|'=OR with worked bilingual examples, days documents default 7 and max ~14, lang documents ISO 639-1 original-language filtering, and n documents default 20 and max 50 — including max bounds absent from 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), resource (recent headlines + summaries), and ordering (newest first), plus a keyword scope. It is clearly distinguishable from sources and compare_coverage, though it does not explicitly contrast itself with the sibling latest_news, which plausibly overlaps in 'recent news' territory.

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 when-to-use phrasing ('news about X', 'what happened with X this week') that maps directly onto query construction. It lacks any explicit when-not/alternative-tool clause, which is the only gap at this tier.

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=false, so the safety profile is covered. The description adds that 'last refreshed successfully' and current item count are exposed, which is useful behavioral context about what the listing reports, but it says nothing about pagination or ordering.

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 resource and its fields, followed by usage. There is a little field-list density but no filler or repetition.

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-shape burden and discharges it by listing the fields. For a trivial no-param read tool with annotations covering safety, this is close to complete; only ordering/pagination details 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?

The tool takes zero parameters, so the baseline is 4. The description adds value by enumerating the returned attributes, which is the natural substitute for parameter documentation on a no-arg lookup tool.

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 curated feeds') and enumerates the fields returned, so the agent knows this is a metadata/lookup tool rather than a content-fetching one. It does not explicitly contrast itself with siblings like latest_news or news_by_topic, but the field list makes the distinction inferable.

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 two concrete use cases: discovering which ids/filters exist, and checking data freshness. That is clear context for when to reach for this tool. It stops short of naming an alternative tool or stating when not to use it, 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.