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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false), and the description adds genuinely useful behavior beyond them: server-side persistence that survives offline, deduplication ('Several sources of one story arrive once'), escalation of high-value items to a quick read, and a plan requirement ('needs the starter plan or above'). It does not contradict the annotations, though it omits how a watch is removed or whether re-calling replaces an existing watch.

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?

Tightly packed into two sentences with no filler; the core behavior is front-loaded and the follow-on clauses each add a distinct fact (offline persistence, dedup, upsell to quick read, plan gate).

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 explains that results arrive via get_updates and how they are presented, which is the key need. However, for a stateful subscription tool with idempotentHint=false, it leaves gaps on watch lifecycle (stopping, duplicate watches on the same symbol) and on limits.

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 75%, with symbols, language and min_value documented and only sentiment relying on its enum, so the schema does most of the work. The description adds the notion of 'scored' news and ties 'high-value ones' loosely to the min_value tiers, but gives no detail on symbol format beyond the schema's examples.

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 states a specific behavior: it maintains a server-side watch that keeps 'matching scored news for symbols' and delivers matches into get_updates. That distinguishes it from the fetch-oriented siblings like get_news or get_news_article, though it never names those siblings or clarifies its relationship to list_news_watches / stop_news_watch.

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?

Usage is implied rather than stated: you call it to have news pushed while offline, and results surface in get_updates. There is no explicit when-not guidance, no mention of the alternative pull tools, and no mention of the sibling that cancels a watch, so the agent must infer the lifecycle.

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