Describe what Horizon covers: ingestion sources with their source= filter values, the regional lenses (region= / dedicated tools), and how to filter. Call this to understand the corpus before querying.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safe read-only behavior. The description adds context about what the tool covers (sources, filters, regional lenses) but does not disclose deeper behavioral aspects like return format, pagination, or edge cases. This meets the minimum bar but does not go beyond it.
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 description is two sentences, front-loaded with the main purpose. The first sentence lists the key contents, and the second provides usage timing. There is zero redundancy and every word earns its place.
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 tool with no output schema, the description fully covers what the tool does and when to use it. It gives a complete mental model for an agent deciding whether to call this before other queries.
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 schema fully covers parameter concerns. The description adds no param details, but none are needed. Baseline for 0 params is 4, and the description's focus on purpose 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 clearly states the tool's function with a specific verb ('Describe') and identifies the resource ('Horizon coverage'). It lists the concrete contents (ingestion sources, filter values, regional lenses), which distinguishes it from sibling query tools like search_news or get_topic_signal.
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 description explicitly says to 'Call this to understand the corpus before querying,' giving a clear when-to-use instruction. It does not name specific alternatives or when-not-to-use conditions, but the context of being a pre-query orientation tool is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly scoped to a specific query type (region, topic, recent items, etc.). The only overlap is get_china_signal as a preset of get_region_signal, but the description explicitly labels it as a shortcut, reducing ambiguity.
All tools use verb_noun with underscores, but the mix of get_, list_, and search_ verbs and the get_china_signal preset (a value rather than a dimension) make it slightly less uniform than a pure get_* set.
10 tools is within the ideal 3-15 range and covers the core operations of an AI news intelligence service without bloat.
The set covers regional/topic signals, recent updates, daily synthesis, regulation, blind spots, search, and related-item exploration. Minor gaps: no tool to fetch full article bodies (paywalled) and no explicit topic list, but core workflows are functional.