Side-by-side wording of one story as left, center and right outlets headline it, plus the words each side uses that the others do not. Give a topic in q and the best-covered matching story is compared. Each source carries a bias score from -2 (left) to +2 (right); 0 is center or non-political.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Topic or headline words to find the story by. | |
| limit | No | How many matching stories to compare. Default 1, max 10. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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.
Add one secure layer between your agents and this server.
Each tool targets a distinct facet: news retrieval, cross-outlet wording comparison, one-sided story detection, and feed health diagnostics. Potential overlap between get_news with view=stories and compare_coverage is mitigated by clearly splitting headline grouping from side-by-side wording analysis.
All four tool names follow a consistent snake_case verb_noun pattern. Three use the get_ prefix (get_news, get_blindspots, get_feed_health) and compare_coverage uses the same verb-first style with a clear object.
Four tools is a well-scoped size for a news bias analysis server. Every tool has a distinct responsibility and the set feels intentionally curated rather than sparse or bloated.
The tool surface covers the full workflow of the domain: retrieving the news, comparing differing coverage of the same event, finding coverage blindspots, and verifying data freshness. There are no obvious pipeline dead ends or major missing operations.
