Skip to main content
Glama

News Feed

news_feed
Read-only

The filtered impact feed — news by megatrend/country/aspect/direction/news_type, across stocks, FX, crypto, COMMODITIES (metals/energy) and private cos. Use for 'negative tariff news on Semiconductors', 'macro news moving European stocks', 'copper / metals news', etc. Near-duplicate stories are MERGED by default (+dup_count); collapse=false for the raw feed. limit = how many (default 20, max 50); narrow the filters rather than paging deep. TIME-SCOPE with from_/to (ISO) or a window ('90d','qtd','ytd','1y'). To COMPARE periods, call once per period and compare the results. ⚠️ News starts 2026-01-01 — older ranges return nothing (no coverage, not 'no news'). megatrend accepts a plain name/slug/concept ('foundry', 'AI chips') — resolved server-side to node id(s).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "news_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoUpper time bound, ISO date `YYYY-MM-DD`.
from_NoLower time bound, ISO date `YYYY-MM-DD`. ⚠️ Ava Advisor NEWS coverage starts 2026-01-01 (nothing before).
limitNoMax rows (default 20, hard cap 50). Keep SMALL + narrow the scope; page/refine rather than dump — heavily-covered assets have hundreds of articles.
aspectNoImpact CHANNEL filter (e.g. `demand`, `competition`, `tariff`, `monetary`). Omit → all channels.
detailNo`compact` (default): per story title, date, publisher, types, impact_score, a short brief and the TOP-3 impacted entities (direction + relevance + one-line why) — fits the client's tool-output limit. `full`: every impacted entity with all its aspects (bigger; use with a small `limit`).
formatNo`json` (default): structured rows. `text`: the same stories as plain readable lines (no JSON keys / quotes / nesting) — about half the size; prefer it when you only need to READ the news to answer.
windowNoNews-recency window: `7d`/`30d`/`90d`/`180d`/`1y` or `mtd`/`qtd`/`ytd`. Omit → a sensible default. (Price history is unaffected — this only scopes the NEWS lens.)
countryNoMarket filter — CSV of ISO-2 codes (e.g. `US` or `CN,TW,HK`). 🌍 If the question names a NATIONALITY or REGION ('European','Thai','Chinese','ASEAN'), put it HERE — never leave it inside a concept/`q`/`gics` field. Enumerate a region into its member ISO-2s yourself (Europe→GB,DE,FR,IT,ES,NL,CH,SE; ASEAN→TH,SG,MY,ID,PH,VN).
collapseNoMerge near-duplicate stories (same article from many outlets) into one row + `dup_count`. Default ON; pass `false` for the raw un-deduped feed.
directionNoFilter by impact direction: `pos` | `neg` | `ambiguous`. Omit → all.
megatrendNoA megatrend node — a name/slug (resolved for you, e.g. `foundry`) or an int node id. CSV for several.
news_typeNoNews CATEGORY (exact names only, e.g. `macro_economic`, `commodity_supply`, `earnings_results`).
only_scoredNoKeep only articles carrying a judged per-entity impact. Omit → all gated articles.
min_relevanceNoMinimum impact relevance, 0–1.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / detail
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "compact",
      +        "full"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "`compact` (default): per story title, date, publisher, types, impact_score, a short brief and the TOP-3 impacted entities (direction + relevance + one-line why) — fits the client's tool-output limit. `full`: every impacted entity with all its aspects (bigger; use with a small `limit`).",
      +  "title": "Detail"
      +}
    • addedInput schema / properties / format
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "json",
      +        "text"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "`json` (default): structured rows. `text`: the same stories as plain readable lines (no JSON keys / quotes / nesting) — about half the size; prefer it when you only need to READ the news to answer.",
      +  "title": "Format"
      +}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "result": {
      +      "anyOf": [
      +        {
      +          "items": {},
      +          "type": "array"
      +        },
      +        {
      +          "type": "string"
      +        }
      +      ],
      +      "title": "Result"
      +    }
      +  },
      +  "required": [
      +    "result"
      +  ],
      +  "title": "news_feedOutput",
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description adds substantial behavior an agent cannot get elsewhere: near-duplicates are merged by default with a dup_count field, collapse=false yields the raw feed, the real coverage floor is 2026-01-01 so older ranges mean 'no coverage' rather than 'no news', and text format is roughly half the size of JSON. Those are exactly the operational traits that change how an agent calls 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.

Conciseness4/5

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

The opening clause front-loads what the tool is, followed by examples, then the dedup/limit/time gotchas in rough priority order. The heavy use of ALL-CAPS, em-dashes, parentheticals and emoji makes it dense and slightly hard to scan, but almost every clause carries a real constraint rather than filler.

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?

With 14 optional parameters, an output schema present, and readOnlyHint covering safety, everything an agent needs to call this correctly is available: time bounds, coverage floor, dedup semantics, output size trade-offs via detail/format, and region-to-ISO guidance for country. No material gaps remain for a tool of this complexity.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds consolidated meaning — that megatrend strings are resolved server-side to node ids, that time scoping accepts either from_/to or a named window, and that limit is capped at 50 with 'narrow the filters' as the recommended strategy. Much of this is restated from the schema, so it reinforces rather than extends, keeping it below a 5.

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

Purpose4/5

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

The description identifies the resource precisely — a filtered news/impact feed — and enumerates the filter axes (megatrend/country/aspect/direction/news_type) plus asset coverage (stocks, FX, crypto, commodities, private cos). That is far more specific than the name 'news_feed' alone. It stops short of naming the sibling tools it competes with (search_news, stock_impact), so an agent must infer the boundary from the filter list rather than being told.

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

Usage Guidelines4/5

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

Usage is unusually well signposted: concrete example queries ('negative tariff news on Semiconductors', 'copper / metals news'), a directive to narrow filters rather than page deep, and an explicit recipe for period comparison (call once per period). The main gap is the absence of explicit alternatives — it never says when to prefer search_news or stock_impact instead, which is the 'when-not' half of the guidance.

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.

Resources