Skip to main content
Glama
SlothyAfk

finance-pulse

News volume and sentiment over time

sentiment_series
Read-onlyIdempotent

Track news volume and bullish/bearish sentiment over time for a single symbol, sector, theme, or topic to spot trend shifts and gauge market mood.

Instructions

News volume and sentiment over time for exactly one of symbol, sector, theme_id or topic_id.

Each bucket: t (UTC start), count, bullish, bearish, neutral, sources (distinct outlets) and score = (bullish - bearish) / count. Buckets with no statements are omitted here. The last bucket is usually the current, still incomplete day or hour: do not read a low last bucket as a drop. interval=hour is for short ranges: pass since/until, and if the range is too long the error says the maximum.

Input Schema

NameRequiredDescriptionDefault
sinceNoISO-8601 time, e.g. 2026-10-01T00:00:00Z
untilNoISO-8601 time, e.g. 2026-10-01T00:00:00Z
sectorNoGICS sector
symbolNoOne ticker or entity code, e.g. NVDA
intervalNoday
theme_idNoTheme id from `themes` or `reference`
topic_idNoTopic (development) id, as returned in topic_id or topics[].id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the read-only/idempotent annotations by documenting bucket contents, the score formula, that empty buckets are omitted, and the important caveat that the last bucket is a partial day/hour and must not be read as a drop. It also discloses the failure mode for oversized ranges (error states the maximum), which is exactly the kind of behavior an agent cannot get from structured fields.

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-loads the purpose and the selector constraint, then the bucket shape, then the two caveats — a logical ordering with no filler sentences. Slightly dense and line-broken mid-thought, but every clause carries information.

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?

With no output schema, the description does the work of explaining the returned bucket fields and score formula, and it flags the partial-last-bucket pitfall. It leaves gaps on the default range when since/until are omitted and on what happens if zero or multiple selectors are supplied.

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 86%, so the baseline is 3; the description earns above that by adding the cross-parameter constraint 'exactly one of symbol, sector, theme_id or topic_id', which the zero-required-parameter schema does not encode at all. It also adds meaning to interval that the bare enum lacks (hour only for short ranges).

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?

States a specific resource and shape: 'News volume and sentiment over time' for exactly one of four entity keys, which tells an agent precisely what comes back. It does not compare itself to siblings like search_statements or trending, so the agent must infer that this is the time-series aggregation rather than the raw statement search.

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

Usage Guidelines3/5

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

Gives one concrete usage rule — 'interval=hour is for short ranges: pass since/until' — plus the self-healing hint that the error message reports the maximum range. It never says when to prefer this over search_statements or how to pick among symbol/sector/theme_id/topic_id beyond 'exactly one', leaving the main routing decision implied.

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