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

With no annotations, the description carries the full burden. It discloses the body=true trade-off ('slower, larger'), lists the exact return fields, and warns about channel case sensitivity. It stops short of discussing rate limits or error behavior, but the core behavioral traits are well covered.

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 front-loads core functionality and usage before diving into the channel list. The confirmed-channels list is long but is operationally necessary for a channel-filter endpoint since the schema lacks enums. The structure is organized with semicolons and no redundant sentences.

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?

The description provides return fields, filters, and a usage directive, which covers the basics. However, given the many sibling news tools (e.g., tengu_v3_intel_news_headlines, tengu_v3_intel_news_crypto), it does not clarify when to use this 'pro' tool over those specialized ones, nor does it mention pagination or error handling. The lack of an output schema increases the need for completeness, which is only partially met.

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 description explains ticker-filtering (comma-separated), channels, and body=true, which maps to three of the four parameters. However, it does not mention the 'limit' parameter (default 25, max 100) or its semantics. With schema coverage at 0%, this partial compensation is useful but leaves a notable gap.

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 identifies the tool as returning 'Real-time newswire stories' with flexible scoping (cross-ticker, ticker-filtered, or by channel) and lists the return fields. It distinguishes itself from headline-only tools by stating 'beyond headlines', but does not explicitly name sibling alternatives, so it falls short of a 5.

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 provides an explicit usage directive: 'Call this when the user wants themed or full-text news beyond headlines.' It also offers concrete channel examples and notes case/apostrophe sensitivity. However, it does not specify when not to use this tool or explicitly reference dedicated alternatives like the headline- or crypto-specific tools.

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