Svodka — Bulgarian News

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

No annotations are provided, so the description carries the full burden. It discloses the key behavior: returns the full summary and all sources. However, it does not mention potential limitations, error cases, or that it is read-only. The description adds some useful context (e.g., id from link) but not comprehensive behavioral disclosure.

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: the first states the core purpose in Bulgarian, the second provides usage context in English. It is concise, front-loaded with the function, and contains no redundant information.

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 single-parameter retrieval tool, the description is fairly complete. It states what is returned (full summary and all sources) and provides workflow context with siblings. However, the lack of an output schema and absence of details about response format or pagination mean it is not perfect, but acceptable given the tool's simplicity.

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 already fully describes the id parameter (type, required, exclusiveMinimum, and an example from a link). Since schema coverage is 100%, the baseline is 3. The description reiterates 'id shown in its link' but adds no new semantic information beyond 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?

The description clearly states the tool returns the full summary of a specific news article by numeric id, including all sources. It explicitly distinguishes itself from siblings by indicating it is used after search_bulgarian_news or get_leading_news to expand a single story, which sets it apart from listing and searching tools.

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 usage guidance: 'Use after search_bulgarian_news or get_leading_news to expand one story by the id shown in its link.' This tells the agent when to invoke the tool, but it does not explicitly mention list_recent_news as an alternative or state when not to use the tool, so it falls short of a perfect 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does explain the output structure (importance-ranked, clustered, includes reason and coverage count), which is useful. However, it does not disclose data source freshness, rate limits, or any side effects, leaving some ambiguity.

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 compact and front-loaded, with each sentence contributing meaning: the return value, the usage trigger, and output details. No redundant wording.

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 low complexity (single optional parameter, no output schema), the description provides sufficient context: what it returns, how it is ranked, and when to use it. The output structure is described well enough without needing an output schema.

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% for the only parameter (limit), which includes min, max, default, and type. The description adds no additional meaning beyond the schema, so the baseline score of 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 clearly states the tool returns an importance-ranked leaderboard of top Bulgarian news stories clustered across outlets, which distinguishes it from siblings like get_article (specific article), list_recent_news (recent list), and search_bulgarian_news (search). The verb 'returns' and resource 'leading news' are specific.

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 tells when to use the tool: 'Use when asked what the top, leading, or breaking news in Bulgaria is right now.' It does not explicitly name alternatives or offer when-not guidance, but the usage context is clear enough.

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?

No annotations are provided, so the description carries the burden for behavioral disclosure. It discloses ordering (newest first), pagination (cursor pagination), and the content type (headlines). It does not explicitly state that it is a read-only operation or describe the return structure, but for a simple list tool, this is reasonably transparent.

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 short and front-loaded, but there is a minor redundancy: 'хронологичен ред' and 'newest first' say the same thing twice. It is still efficient and gets to the point quickly, but has slight waste.

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 simplicity (read-only list with two optional parameters, no output schema), the description adequately covers the main aspects: what it returns, ordering, pagination, and usage guidance. The absence of an output schema is compensated by the description's mention of 'headlines' and 'news', which sufficiently informs the agent of the expected return content.

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 clear descriptions for both limit and cursor. The description adds context that the cursor is used for pagination and that results are chronological, but it doesn't add significant meaning beyond the schema's parameter descriptions. 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 clearly states the tool returns the latest news in chronological order (newest first), which is a specific verb+resource+scope. It also differentiates itself from search by saying 'Use to browse the latest headlines rather than search a specific topic', matching sibling search_bulgarian_news.

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 provides usage guidance: 'Use to browse the latest headlines rather than search a specific topic.' This names the alternative use case (searching a specific topic), which maps to the search_bulgarian_news sibling, and implicitly distinguishes from get_article (getting full article) and get_leading_news (leading/top stories).

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?

No annotations are provided, so the description carries the full burden. It clearly discloses that this is a semantic search, that results are summarized stories, and that source outlets and canonical links are returned. It also notes language effectiveness ('Queries work best in Bulgarian'). It does not mention limitations like pagination or rate limits, but for a read-only search tool this is reasonably transparent.

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 compact, with no filler. It front-loads the core purpose in Bulgarian, then adds usage scope, return contents, and language guidance in three short sentences. Every sentence contributes necessary information.

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 search tool with two parameters and no output schema, the description adequately covers purpose, sources, result contents, and usage context. Combined with the schema's parameter details, it gives an agent enough to select and invoke the tool correctly without needing more.

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% with descriptions and examples for both parameters, so baseline is 3. The description adds meaningful value by advising that queries work best in Bulgarian and clarifying that results are summarized stories—context that helps select parameter values.

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: 'Семантично търсене в агрегирани български новини' (semantic search in aggregated Bulgarian news), naming concrete outlets. It distinguishes from siblings by emphasizing search over arbitrary topics versus specific article retrieval or recent-news listings.

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 states when to use it: 'Use for any question about current events, people, places, or topics in Bulgaria.' It does not explicitly mention alternatives or exclusions, but the context is clear and actionable.

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