Skip to main content
Glama
Mohammed-Jameal-J

NewsBlog Composer MCP

verify_news

Confirm a news headline is real by searching providers and counting independent publisher matches; returns false unless at least two sources or one official source corroborate it.

Instructions

Step 2 - confirm a SPECIFIC headline is real and corroborated. Check that a headline describes a real, corroborated story.

Searches every configured news provider, keeps only results that actually match the headline, and counts how many INDEPENDENT publishers are carrying it. Returns is_legit=false unless at least two independent publishers match, or a single primary/official source does.

This verifies a headline; it does not find one. If the user gave you a topic ("today's AI news") rather than a headline, call find_stories first. Note that an old headline will correctly return old sources - days limits how far back to look.

Do not draft anything if is_legit is false. Feed fetchable_urls to fetch_article_facts, and use reference_candidates as the reference list - those are real publisher URLs. Some providers return aggregator redirects that still name the outlet; they count toward corroboration but are not usable as links, and build_schema rejects them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo
limitNo
titleYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the search-across-providers behavior, the two-publisher corroboration threshold (or one primary/official source), the is_legit=false default, and the aggregator-redirect edge case that counts for corroboration but is rejected by build_schema. This is unusually rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the 'Step 2' role and the core verification rule, then the alternative and downstream feeding. Every sentence earns its place, though it is dense enough that a couple of clauses could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description names the key return fields (is_legit, fetchable_urls, reference_candidates) and explains the pass/fail rule, which is what an agent needs. Minor gap: the effect of the `limit` parameter is left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains `days` ('limits how far back to look') and implies `title` is the headline under test, but `limit` is never mentioned and the title format/expectations remain unspecified. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('confirm a SPECIFIC headline is real and corroborated') with an explicit scope distinction: 'This verifies a headline; it does not find one.' This contrast against find_stories lets an agent route correctly without opening sibling schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use routing: 'If the user gave you a topic ... call find_stories first,' plus a hard gate ('Do not draft anything if is_legit is false'). It also names downstream consumers (fetch_article_facts, build_schema) with the exact fields to pass, so usage is fully specified.

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