Skip to main content
Glama
SlothyAfk

finance-pulse

by SlothyAfk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Screen symbols or sectors by news attention

screen
Read-onlyIdempotent

Ranks stocks or GICS sectors by news attention, showing which tickers are suddenly in the news. Sort by mention change, volume, sources or score over 24 hours, 7 days, or custom intervals.

Instructions

Rank symbols (or the GICS sectors) by news attention. Use for "which tickers are suddenly in the news".

period: d = last 24 hours, w = last 7 days, window = all the history the plan includes; or pass since (and until) to count any interval. sort=change ranks by the rise in mentions against the period (or equally long interval) before. change is null when there is nothing before to compare with: for period=window, for an interval given only by until, and for an interval whose preceding interval reaches before the plan's history. Use sort=mentions then. Each row: mentions, topics, sources (distinct outlets), sentiment counts, score and change; symbol rows also carry name, kind and the counts over statements naming only that symbol (mentions_single, score_single). Only for rank=symbols: sector limits the screen to one sector; min_mentions drops rarely mentioned codes; entity_kinds narrows the kind of entity (reference lists the kinds). Without it the list mixes companies with rates, commodities and central banks; pass "equity,etf" for tradable tickers.

Input Schema

NameRequiredDescriptionDefault
rankNosymbols
sortNochange
limitNoHow many rows to return
sinceNoStart of a custom interval (ISO-8601) to count instead of `period`
untilNoEnd of the custom interval (ISO-8601); omit for up to now
periodNod = last 24 hours, w = last 7 days, window = all the history the plan includesd
sectorNoGICS sector
entity_kindsNoComma-separated entity kinds from: equity, etf, index, rate, fx, crypto, commodity, org, private, country. E.g. "equity,etf"
min_mentionsNoLeave out codes with fewer mentions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.1
    • changedInput schema / properties / entity_kinds / description
      Previous value: -"Comma-separated entity kinds, e.g. \"equity,etf\""New value: +"Comma-separated entity kinds from: equity, etf, index, rate, fx, crypto, commodity, org, private, country. E.g. \"equity,etf\""
    • changedInput schema / properties / limit / maximum
      Previous value: -500New value: +100
    • changedInput schema / properties / period / description
      Previous value: -"d = 24 hours, w = 7 days, window = everything held"New value: +"d = last 24 hours, w = last 7 days, window = all the history the plan includes"
    • addedInput schema / properties / since
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Start of a custom interval (ISO-8601) to count instead of `period`",
+  "title": "Since"
+}
    • addedInput schema / properties / until
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "End of the custom interval (ISO-8601); omit for up to now",
+  "title": "Until"
+}
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), but the description adds substantive behavior beyond them: the exact conditions under which `change` is null and the recommended fallback, and the caveat that without entity_kinds the list mixes companies with rates, commodities and central banks. It also enumerates what each returned row contains, which matters because there is no output schema.

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?

Purpose and the key "when" are front-loaded, and nearly every clause carries new information. Some sentences are dense run-ons, particularly the null-change enumeration, which costs one read to parse but does earn its place.

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 nine parameters, no output schema and no required fields, the description does the important work: row shape, default-mixing caveat, cross-parameter scope (sector only with rank=symbols), and null semantics. Minor gaps remain around ordering of results and how `limit` interacts with min_mentions filtering, but nothing an agent needs in order to call it correctly is absent.

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?

It adds real meaning over the schema — sort=change semantics, the null-change conditions, that sector applies only when rank=symbols, and what min_mentions filters out. But schema coverage is already 78%, so much of this (period, since/until, sector, entity_kinds) is partly redundant with the schema descriptions, and `limit` is untouched. Solid but largely reinforcing existing field docs.

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 opening sentence gives a specific verb (rank), a specific resource (symbols or GICS sectors) and the ranking axis (news attention), plus a concrete question it answers: "which tickers are suddenly in the news". That framing distinguishes it immediately from siblings like search_statements, get_symbol, or sentiment_series.

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?

It gives clear contextual guidance: use it for sudden news attention, pick period vs since/until for the interval, and explicitly says "Use sort=mentions" when `change` is null. It also advises passing entity_kinds="equity,etf" for tradable tickers. What's missing is explicit routing against siblings — notably how it differs from `trending`, which overlaps on the 'what's hot now' use case.

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

Deploy Server

Other Tools