Skip to main content
Glama

Headlines and news search

news

Newest headlines from a deduped, tiered direct-feed pile (official press, wires and majors). Pass q to keyword-search the retained multi-day archive instead; category='ai' or 'crypto' return the high-signal curated cuts. Snapshot of ingested feeds, not a live web search. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoKeyword query — switches to archive search.
limitNoMax headlines.
sinceNoOnly items after this instant (ai/crypto cuts).
categoryNoHeadline category; 'ai' and 'crypto' are curated high-signal cuts.
x_paymentNoOptional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data.

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description fully discloses key behaviors: deduped and tiered sources, multi-day archive retention, snapshot freshness, and the required two-step x402 payment process. This goes beyond what the input schema reveals and sets accurate expectations for the agent.

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

Conciseness5/5

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

Three dense sentences carry high information density. The main purpose is front-loaded, and every clause serves a purpose (source type, archive mode, curated categories, freshness, payment flow, alternative tool). No filler or redundancy.

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

Completeness5/5

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

Despite 5 parameters and no output schema, the description covers all decision points: how to get the newest headlines, how to search the archive, special category behavior, and the exact paid-call procedure. It also notes the tool is not a live web search, which prevents misuse. Enough for an agent to invoke correctly.

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

Parameters5/5

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

Even though schema coverage is 100%, the description adds crucial semantics: 'q' switches to archive search, 'category' with 'ai'/'crypto' returns curated cuts, and 'x_payment' has a multi-call payment protocol. This is added meaning beyond the schema's type/examples.

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?

The description starts with 'Newest headlines from a deduped, tiered direct-feed pile' – a specific verb+resource with clear scope. It distinguishes from sibling tools by stating 'Snapshot of ingested feeds, not a live web search' and references the separate `pricing` tool.

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 guidance is given for when to use keyword search ('Pass q to keyword-search...'), curated categories ('category='ai' or 'crypto' return the high-signal curated cuts'), and the payment flow ('call without x_payment to receive this call's exact terms...'). It also names the `pricing` tool as an alternative for price discovery.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool serves a clearly distinct function—data discovery, holidays, icons, OCR, news, PDF extraction, pricing, URL reading, data requests, screenshots, timezone, and weather. There is no overlap in purpose; even read_url and screenshot_url differ by output format (markdown vs PNG).

Naming Consistency4/5

All tool names use lowercase snake_case and are readable, but the pattern is not uniformly verb_noun—some are nouns (holidays, news, pricing, timezone, weather) while others are verb_noun (find_data, read_url). This is a minor inconsistency that doesn't impede predictability.

Tool Count5/5

With 12 tools, the server sits comfortably within the ideal 3–15 range. Each tool earns its place covering a distinct web utility, and the count matches the broad but well-defined scope of a general-purpose web toolbox.

Completeness4/5

The tool surface is fairly complete for a general-purpose web utility server, covering common tasks like fetching, extracting, searching, and checking time/weather/holidays, plus meta tools (pricing, request_data). Minor gaps like a generic text summarizer or video tool exist, but nothing critical for the intended purpose.

Resources