Sidewise

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

With no annotations, the description carries the behavioral burden. It discloses the core output (headline comparisons, unique words, and bias scores), the selection mechanism (best-covered matching story), and the scoring range (-2 to +2). This is solid transparency, though it does not mention potential limitations such as source scope or timeout 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?

The description is two sentences with every part contributing: the output format, the input requirement, selection behavior, and bias scale. It is front-loaded and free of 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?

The tool has only two parameters and no output schema, but the description gives enough detail about the returned content for an agent to understand what happens. It is slightly incomplete in not explaining how 'limit' interacts with the comparison, but that is already covered by the 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 coverage is 100%, so the schema already documents 'q' and 'limit'. The description restates 'q' but adds no new semantic detail beyond what the schema provides. The minimum viable 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?

The description clearly states what the tool does: it produces a side-by-side comparison of how one story is headlined by left, center, and right outlets, and highlights the unique words each side uses. It also distinguishes itself from sibling tools by focusing on comparison rather than general news retrieval, blind spots, or feed health.

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 gives clear usage context: provide a topic via the 'q' parameter and the best-covered matching story is compared. It does not explicitly mention alternatives or when not to use it, but the purpose is specific enough that an agent understands when to invoke it.

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?

With no annotations, the description carries the burden. It explains the concept of blindspots and the bias score, but does not disclose response format, pagination, or whether limit defaults are applied. The read-only nature is implied but not stated. It adds moderate value beyond the tool name.

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, each earning its place: the first defines the tool's output, and the second explains the bias scoring and use case. It is concise, front-loaded, and free of fluff.

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 only one parameter, no output schema, and no annotations, the description offers sufficient context for an agent to understand what the tool does and when to use it. It explains the underlying concept and scoring, but lacks explicit details about the return structure or limit behavior.

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% for the only parameter (limit), which is described as 'Max stories, up to 200.' The description does not mention limit, so it adds no extra meaning beyond the schema. 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 clearly states the tool returns stories covered by only one side of the political spectrum, distinguishing it from the sibling tool get_news. It also explains the bias score scale, adding specificity to the resource.

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 use case: 'finding what a given audience is not being told.' It implies this tool is for blindspots rather than general news, but does not explicitly name when not to use it or compare with get_news.

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?

With no annotations present, the description itself carries the behavioral burden. It discloses valuable behavior: that this tool checks liveness of feeds, reports staleness, and distinguishes real data from fallback data. This goes beyond the tool name and alerts the agent to a data-quality pitfall, though it does not mention auth, rate limits, or side effects—none of which seem critical for a health-check tool.

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 succinct sentences with no filler. It leads with the core stateful output, then adds a concrete operational cue. Every clause contributes meaning.

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 no-parameter health-check tool, the description explains what it does and when to use it. It does not detail the exact return shape, but since there is no output schema, the agent can still infer that the answer includes a list of feed names and a completeness/staleness flag. It is slightly minimal but not incomplete for its 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 tool has zero parameters, so there is nothing for the description to add beyond the trivially complete input schema. The privacy and completeness semantics in the description are relevant once the tool returns, not for parameter binding. Baseline 4 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 purpose: reporting which underlying news feeds answered on the last pull and whether the served data is complete or a stale fallback. This clearly distinguishes it from siblings like get_news or compare_coverage by focusing on feed health rather than content, coverage, or blindspots.

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 gives a clear usage context: check this before treating an empty or one-sided result as real. It does not explicitly name when not to use it or compare with alternatives, but the guidance is concrete enough to direct an agent confidently.

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?

With no annotations present, the description carries behavioral transparency. It reveals the 16/14 feed news-room scope, the -2 to +2 bias scoring model, and the distinction between flat and story-grouped results. It does not disclose response structure or possible pagination behavior, but these are not central to invoking the tool.

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, no filler, and the the most mission-critical fact is front-loaded: it returns current headlines from a specific feed set. Every remaining sentence provides distinct context for choosing a viewpoint view.

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 six optional parameters, complete schema coverage, no output schema, and no nested objects, the description is adequate enough to select and invoke the tool correctly. The missing return-format detail is a mirad concern, but it does not block correct invocation.

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 a baseline of 3 is appropriate; the description goes beyond it by explaining what view=latest versus view=stories actually means and by defining the bias score scale. This extra semantic context is genuinely useful for param selection.

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 the tool provides current headlines from a concrete set of feeds/newsrooms and explicitly clarifies the political-bias context. It is clearly about news retrieval, but it does not explicitly differentate itself from the sibling tools beyond the obvious differrence in name.

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 gives clear guidance on how to use the view parameter: latest for a reverse-chronological flat feed and stories for event clustering. It does not exclud or route away from the sibling tools, so it lacks the explicit alternative guidance needed for a 5.

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