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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the access restriction ('paid plans only') and hints at pagination via the 'page' arg, but it does not disclose return format, rate limits, or sorting behavior. It provides some value beyond annotations but with clear gaps.

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 front-loaded with a clear summary, followed by a compact args list and two illustrative examples. It is efficient, though the args list partly duplicates schema information, preventing a perfect score.

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?

This is a complex 20-parameter tool with no output schema. The description provides examples and key parameters but does not describe the response structure, pagination navigation details, or error behavior. The rich schema and annotations help, but the description alone leaves some gaps for a complete understanding.

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. The description adds practical examples (e.g., q='tesla', from_date='2025-01-01', to_date='2025-01-31') and highlights key parameters like q, from_date, to_date, size, and page, making parameter usage more concrete.

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 explicitly states 'Search historical news articles (paid plans only)' with a specific verb and resource. It clearly distinguishes from sibling tools like 'latest', 'crypto', 'market', and 'sources' by focusing on the 'archive' and 'historical' aspect.

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 provides clear context: it is 'useful for research and historical analysis' and notes 'paid plans only'. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full usage-guideline clarity.

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 indicate this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral details: results are limited to the past 48 hours unless timeframe is set, supports pagination tokens, and provides concrete query examples. It does not disclose response structure or rate limits, but the annotation coverage lowers the burden.

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 well-organized with a summary, argument list, and examples. It is slightly redundant between the first sentence and 'Dedicated endpoint...' but otherwise each section serves a clear purpose and the examples are compact.

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 at least states the tool returns articles and constrains them to crypto topics and a 48-hour window. It covers the primary parameters and gives actionable examples. It could be more complete by describing the article fields or default paging behavior, but it provides enough to select and invoke the tool correctly.

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 already covers all 20 parameters with descriptions, giving a baseline of 3. The description adds value by highlighting the most relevant parameters (q, coin, sentiment, timeframe) and providing purpose-driven examples like 'Bitcoin news: q="bitcoin" or coin="BTC"' that clarify how to combine them.

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 'Fetch cryptocurrency-specific news articles,' naming a specific verb, resource, and domain. It further distinguishes itself from siblings by noting this is a 'dedicated endpoint for crypto/blockchain news with coin-specific filtering' and by limiting results to the past 48 hours.

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 clearly conveys when to use the tool: for cryptocurrency/blockchain news, especially with coin-specific filtering or sentiment. It does not explicitly mention alternatives or when-not-to-use cases, but the 'dedicated endpoint' phrasing and 48-hour window give enough context to differentiate from the named siblings.

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 mark the tool as read-only and non-destructive. The description adds valuable behavioral details: rate limits (10 free vs 50 paid), pagination via token, and lookback timeframe constraints. These go beyond the structured annotations and help set correct expectations.

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 well-structured with a concise summary, a bulleted parameter list, and concrete examples. Every sentence serves a purpose, and the format is easy to scan. The length is appropriate for a feature-rich news API.

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?

Given the tool's complexity (19 parameters, no output schema) and the rich sibling toolset, the description covers purpose, key parameters, rate limits, and usage examples. It doesn't fully describe the response structure, but this is partially mitigated by the clear scope and familiar news-article concept. The description is complete enough for an agent to select and invoke the tool correctly.

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 input schema covers all 19 parameters at 100% coverage, giving the baseline of 3. The description adds value by providing usage examples and clarifying semantic relationships (e.g., timeframe hours/minutes, sentiment values, country codes). This pushes it above the baseline but not to 5 since the schema already documents each parameter thoroughly.

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 'Fetch the latest news articles from the past 48 hours worldwide,' which combines a specific verb, resource, and temporal scope. The scope distinguishes it from siblings like newsdata_archive and newsdata_crypto, making the tool's role clear.

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 provides a clear context of use: fetching recent, worldwide news with various filters. It includes examples of valid queries and parameter combinations. However, it does not explicitly name sibling tools or state when to prefer this over alternatives, so it falls short of a 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, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the 'beta endpoint' status and the 48-hour lookback limit, which are useful behavioral constraints, but it does not disclose rate limits, pagination behavior beyond the schema, or any other operational details. There is no contradiction with 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?

The description is well-structured with a summary line, an args list, and examples. It is front-loaded with the key purpose and does not ramble. The second sentence ('Get real-time market news...') adds some redundancy but also context, making it acceptable. Overall, it is appropriately concise for a tool of this complexity.

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?

Given the tool has 19 parameters and no output schema, the description provides only a partial parameter overview and omits many schema params from its Args list. However, the schema fills that gap. The description adds key constraints (past 48 hours, beta status) but lacks explicit sibling differentiation and does not explain the return format or pagination flow beyond the schema. It is adequate but not comprehensive.

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 input schema provides descriptions for all 19 parameters (100% coverage), so the baseline is 3. The description's Args list repeats some schema info and adds example combinations (e.g., q='market crash', sentiment='negative'), but it omits many parameters and does not provide new semantic meaning beyond the schema descriptions. The examples are mildly additive but not essential.

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 'Fetch financial and stock market news' with specificity about content types and a 48-hour time range, which distinguishes it from the crypto/latest/archive/sources sibling tools. However, it does not explicitly name or compare against these siblings, so it lacks the explicit differentiation seen in higher-scoring examples.

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 examples (Apple stock news, market crash coverage, tech earnings) imply common use cases, but the description does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or 'use this instead of X' guidance. The usage context is implied rather than direct.

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 and idempotentHint, so the tool is known safe. The description adds behavioral clarity by specifying filtering options and showing example filter combinations, which helps the agent anticipate results. It doesn't mention rate limits or pagination, but these are less critical given the read-only nature.

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 well-organized with a summary, a bulleted Args list, and examples. It is concise and all information serves a purpose, with no 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?

The tool is simple and read-only, with all parameters documented and examples provided. No output schema exists, but the description implies the return is a list of sources. It could be more explicit about response format, but given the simplicity, it's adequate.

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 baseline is 3. The description adds value with concrete examples (e.g., language='en', category='technology') and clarifies prioritydomain values, making parameter usage more actionable.

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 'List available news sources with filtering options' and explains 'Browse and discover news sources indexed by NewsData.io'. This specifies the verb (list) and resource (sources), distinguishing it from sibling tools that handle news articles.

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 provides context through examples like 'English tech sources' and 'US news sources', implying when to use the tool for source discovery. It doesn't explicitly exclude other tools but clearly scopes the use case to source listings rather than news content.

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