Horizon: AI News & AI Regulation Tracker

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely valuable epistemic context the annotations cannot: "invisible" means zero pickup in Horizon-tracked Western feeds, not a claim about all media. That is a meaningful caveat about how results should be interpreted, though it says nothing about how counts are ranked or how far back the corpus reliably goes.

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: definition first, decision-framing question second, methodological caveat last. The core definition is front-loaded and nothing is repeated.

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 an output schema present, return shape needn't be described, and annotations cover safety. Between them, the description, schema and output schema give the agent enough to decide when to call it, what the numbers mean, and the limits of the claim.

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 parameters (days, limit) carry defaults and ranges in the schema itself, so the description needs to add little. It adds nothing about parameter semantics — no hint about how widening days affects blind-spot detection or why limit caps at 50. 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?

The description defines the resource with unusual precision: companies, models and people covered by Chinese/East-Asian, European and Latin-American press but absent from Western/global feeds, ranked with per-region item counts. That is far more than a restatement of the name. It stops short of a 5 because it never contrasts itself with the overlapping siblings get_region_signal / get_china_signal, leaving the agent to infer that this is the cross-region gap view rather than a single-region view.

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 framing question "what is Western tech media missing right now?" gives a concrete trigger for selecting this tool, which is clear usage context. It offers no exclusions or named alternatives, so an agent weighing this against get_region_signal or search_news gets no explicit routing rule.

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, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond annotations: it is a shortcut equivalent to get_region_signal with region "china", the output is ranked by momentum, and it surfaces sources Western feeds often miss. It does not discuss pagination or rate limits, but those are minor here.

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 with no filler. The shortcut equivalence and scope are front-loaded before the alternative-tool guidance.

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 an output schema, full parameter coverage, and safety annotations already present, the description provides everything an agent needs: what the tool retrieves, how it relates to the sibling, and when to use the alternative.

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 schema descriptions cover 100% of parameters, including the limit default and cap, so the description need not repeat them. It adds no additional parameter semantics beyond what the schema already provides, which is the expected baseline when coverage is complete.

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 (shortcut for get_region_signal), resource (China & East-Asia AI signal), and scope (region "china"), and names the sibling it is distinct from. An agent can distinguish it from get_region_signal 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?

Explicitly says to prefer get_region_signal if querying more than one region, giving a clear condition that selects the alternative. No inference needed for tool selection.

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=true, destructiveHint=false, openWorldHint=false), and the description adds real context beyond that: the source corpus (HN, Reddit, Bluesky, arXiv, HF, lab blogs, tech press across three regions, legislative sources) and the once-daily curated cadence. It stops short of stating archive bounds, freshness timing, or result size, which is why it is a 4 rather than 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?

The core purpose is front-loaded in the first clause, and the routing hint comes before the parameter notes. The source enumeration is long but earns its place by establishing coverage trust; four sentences are close to the minimum for this much content, though the source list could be tightened slightly.

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 an output schema present, the return shape need not be described, and the description still characterizes what categories of content come back. Parameters are covered, the sibling alternative is named, and the curated-daily model versus incremental updates is made clear — nothing an agent needs in order to call this 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%, so both parameters are already fully documented in the schema, making 3 the baseline. The description restates the date format and adds only a marginal nuance ('a shorter result' for top_stories_only) rather than new semantics such as behavior for out-of-range dates or what 'latest' means.

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 opens with a specific verb+resource ('Today's AI briefing, or any past day's') and enumerates the concrete contents: top stories with sources and corroboration labels, emerging signals, new entrants, regulation updates. It also explicitly contrasts itself with the sibling get_new_since, so an agent can distinguish 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?

It gives an explicit alternative and the condition that selects it: 'for raw item-level updates since your last check, use get_new_since instead.' It also states the selection conditions for both parameters (pass a date for a past day, set top_stories_only for a shorter result).

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, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: a fixed 30-day window, and two explicit disclaimers (not a score, not a truth judgement) that prevent an agent from over-reading the output.

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?

The first sentence front-loads the core comparison, and the disclaimers land before the rhetorical question. The opening clause ('how much of the claim activity Horizon holds provenance data for is self-reported...') is syntactically tangled and could be shorter, but no sentence is redundant.

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?

An output schema exists, so return values need no prose explanation, and annotations plus the 30-day scope cover most behavioral questions. What remains unaddressed is edge-case handling — what happens for an unknown or ambiguous entity name — which matters for a single-required-string lookup.

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 schema already supplies a concrete example, so the baseline is 3. The description adds meaning on top by stating the entity may be a company, a model, or a person, which broadens and disambiguates the parameter's accepted domain beyond the single example.

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 names a specific verb-and-resource combination (provenance breakdown for a single entity) and defines the two quantities being compared: self-reported versus independently evaluated claim activity. This is clearly distinct from the sibling signal/search tools, which report topical or regional activity rather than an attribution split.

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?

It supplies a concrete use case ('is the buzz around X coming from X?') and explicitly bounds the output as descriptive counts over the last 30 days, not a score or truth judgement. It never names an alternative tool or states when not to use it, so it falls short of a full when/when-not specification.

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=true, destructiveHint=false, openWorldHint=false), so the description adds value with the polling model: incremental, oldest→newest, cursor chained from nextCursor. It doesn't disclose rate limits or what happens to items that fall out of the retention window, which would be the remaining high-value additions.

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 essential framing ('Incremental poll') and then packs scoping, ordering, pagination, alternative routing, first-call behavior, and return shape into a few dense clauses. Nothing is redundant with the schema in a wasteful way.

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 tool with full schema coverage, an output schema, and safety annotations, the description covers the only real ambiguity: how to start and continue the cursor loop. Return fields are mentioned briefly and the output schema handles the rest.

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 parameters are documented there, including the default/cap on limit and the cursor's origin. The description reinforces the cursor lifecycle and the default fetch behavior but adds 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 ('Incremental poll: raw item-level AI news') plus the ordering ('oldest→newest') and the pagination artifact ('nextCursor'). It explicitly contrasts itself with get_daily_briefing, so an agent can distinguish it from siblings 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 an explicit selection rule ('use this for "what's new since I last checked"') and names the alternative for the other case ('for the curated once-daily synthesis use get_daily_briefing'). It also tells the agent what to do on first use ('Omit cursor for the latest items plus a cursor to start polling from').

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: ranking is by momentum, items are relevance-scored, and local-language press is translated into English — useful signals about content provenance and ordering. It does not mention freshness windows or result caps, 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 tight sentences: what it is, what makes it special, and what it returns. The differentiator from get_china_signal is front-loaded immediately after the definition, 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?

For a two-parameter read tool with an output schema, annotations, and full schema coverage, everything an agent needs to call it correctly is present. The description even previews return fields (titles, sources, links), which is bonus rather than a requirement given the output schema exists.

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%, with the region enum and a documented default/cap for limit ('default 15, cap 40'), so the schema already carries parameter meaning. The description restates the region set but adds nothing about how limit interacts with ranking or truncation. 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 ('The current AI signal for a region'), enumerates the valid regions, and characterizes the payload as relevance-scored items on models, labs, and analysis ranked by momentum. It also explicitly distinguishes itself from sibling get_china_signal, so an agent can separate the two 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 routes the agent: 'The canonical regional tool; get_china_signal is a preset of this with region china' tells the caller to prefer this tool and how the sibling relates. It stops short of saying when to choose get_topic_signal or get_daily_briefing instead, so it is clear context without full when-not guidance.

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, destructiveHint=false and openWorldHint=false, so safety is covered; the description adds non-obvious context: the breadth of jurisdictions covered, the stage taxonomy attached to each item, and the heavy skew toward state bills that drives result volume. It doesn't state freshness/update cadence, which matters for a tool named 'updates'.

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 coverage, followed by the single most useful operational tip. Every clause earns its place; nothing repeats the annotations or 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?

An output schema exists so return values need not be described, and annotations carry the safety profile. What remains — coverage scope, stage values, filter strategy, volume skew — is all present, leaving an agent able to call it correctly on the first attempt.

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 baseline is 3, but the description adds real semantic value for jurisdiction by explaining that us_state dominates results and filtering narrows them. The limit parameter (default 50, cap 100) is left entirely to 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 ('Current AI legislation headlines') with explicit coverage scope (US Congress/federal agencies, US state legislatures, UK Parliament, EU) and the data shape (legislative stage values). This is enough to distinguish it from generic siblings like search_news or get_topic_signal 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?

Gives actionable usage context: 'State bills are the largest share by far; filter with jurisdiction to narrow' tells the agent why and when to pass the jurisdiction param. It stops short of naming alternatives or stating when-not-to-use this tool versus search_news or get_region_signal.

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 read-only, non-destructive, closed-world behavior. The description adds useful behavioral context beyond annotations: similarity is embedding-based, results are recent, and output includes titles, sources, scores, and links. It does not describe rate limits or auth, but those are not necessary here.

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 with no wasted text. The core 'more like this' purpose is front-loaded, followed by the id provenance and return shape.

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 simple read-only related-items tool with rich annotations, fully documented parameters, and an output schema, the description provides enough context to invoke it correctly. No critical behavior or parameter information 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 the schema already defines both parameters. The description adds some useful provenance for the id parameter by naming tools that produce valid ids, but it does not add limit semantics beyond what the schema documents. A 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?

The description states a specific verb-like operation ('Semantic more like this') and resource ('most similar recent items'), and it distinguishes the tool from search/get-new workflows by explaining that it takes an item id and returns embedding-similar results. An agent can identify its role 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?

It clearly indicates the usage context: the caller should already have an item id from get_new_since, search_news, or the feed. It does not explicitly state when not to use it or name an alternative for broad search, but the intended workflow 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 declare readOnly, non-destructive, closed-world, so safety is covered. The description adds non-obvious behavior beyond them: items are recent, relevance-scored, and ranked by momentum — telling the agent the output ordering is momentum-based, not chronological.

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 with the purpose front-loaded and the sibling comparison second. No filler or 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?

An output schema exists, so return-value detail is not required, and the description conveys the semantic shape (ranked, relevance-scored items). Minor gap: nothing about how momentum is computed or whether results are paginated, but that's beyond the stated contract.

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%: the enum slugs and the limit default/cap (15/40) are fully documented in the schema. The description adds no parameter-level detail (e.g., what 'momentum' means for ranking or how limit interacts with ranking), so 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 ('get') and resource ('current AI signal for a topic') plus the content type (recent, relevance-scored items tagged with that topic). The contrast with get_region_signal makes the distinction from the nearest sibling explicit.

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?

'Like get_region_signal but sliced by subject instead of geography' routes the agent to the right sibling by contrast, which is strong usage guidance. It stops short of an explicit when-not condition or prerequisite, so it isn't a full 5.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds behavioral value by clarifying that the response is reference metadata (source= values, regional lenses, filtering guidance) rather than actual news records, and it cross-references 'dedicated tools' for regional lenses — useful routing information beyond 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?

One compact sentence that front-loads what is returned and ends with the call condition. Every clause earns its place and nothing is repeated from the annotations or 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?

For a zero-parameter, read-only introspection tool with an output schema and full annotations, the description tells the agent what it will learn and when to use it. Only minor gaps remain, such as whether the content is static or cheap to call repeatedly.

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 zero parameters, the baseline is 4. The description goes further by documenting the vocabulary that other tools' parameters accept (source= and region= filter values), which is meaningful semantic content even though there are no parameters of its own.

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 names a specific verb ('Describe') and a concrete resource (Horizon's ingestion sources, source= filter values, regional lenses, and filtering guidance). It implies a distinction from the query siblings via 'before querying', but never names an alternative, so differentiation is inferred rather than explicit.

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?

It gives a clear call condition: 'Call this to understand the corpus before querying.' This is more than implied usage, though it stops short of stating when not to call it (e.g., if the schema of source values is already known).

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, non-destructive, closed-world behavior and an output schema exists, yet the description still adds non-obvious traits: a hard cap of 3 results, ranking by momentum, a 14-day window, and that ids are consumable by get_related. Missing only rate-limit or empty-result 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?

A single sentence that front-loads the core capability and packs scope, result cap, ranking, and follow-up in the tail. 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 annotations and an output schema, the description covers purpose, scope, result size, and the downstream id pattern; nothing an agent needs to invoke it correctly is 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?

With a single fully documented parameter, the schema baseline is high, but the description adds real meaning beyond 'Search terms' by specifying that matching is against titles only and is time-bounded. No format/syntax guidance for multi-term queries.

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 ('title search over AI news') plus scope (last 14 days) and behavior (top 3 by momentum, links and item ids). An agent can distinguish it from siblings like get_topic_signal or get_new_since 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?

Frames it as a 'quick title search' with a bounded window, which signals it is the lightweight lookup rather than a broad retrieval, and it explicitly hands off ids to get_related. It does not say when to prefer get_topic_signal, get_china_signal, or get_new_since instead, so routing is only partly covered.

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