Skip to main content
Glama
Sign In
Bullrun

Bullrun

by ferinator
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get company news with sources and freshness

get_company_news

Retrieve cached company news for a specific ticker in reverse chronological order, with optional date cutoff and result limit for headline and source research.

Instructions

Get cached company news for one exact Bullrun ticker, newest publication first, with publisher, source URL, publication date and stored-fetch freshness when recorded. Optional since cutoff and limit up to 50; only the newest 50 stored articles are searched. Useful for company headlines and article sources; use get_corporate_calendar for scheduled earnings/dividends and get_earnings_call_transcript for call text. Reading news also registers demand and requests a best-effort background cache refresh; this response does not wait for or confirm a refresh. Cached/empty/stale results do not establish that no new events exist. Does not change portfolios or place trades.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum returned articles, newest publication first. Up to 50 cached source articles are read before cutoff filtering.
sinceNoInclusive publication-time cutoff. YYYY-MM-DD means midnight UTC; timestamps need an explicit Z or UTC offset. Applied to the newest 50 stored articles, not a full historical news archive.
tickerYesBullrun company ticker, e.g. AAPL, SAP, ABBN or 6324.T. Use the listing ticker returned by search_stocks. US/European examples: AAPL, BMW, NESN. Most Asian listings keep their exchange suffix (6324.T, 0700.HK); some use bare codes (005930). Native or suffixed forms resolve only when one listing matches; search by company name or ISIN if unsure.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.0
    • changedInput schema / properties / ticker / description
      Previous value: -"Bullrun company ticker, e.g. AAPL, SAP, ABBN or 6324.T. Bullrun tickers: US and most European listings use the plain local symbol (AAPL, BMW, NESN, ABBN); most Asian and Indian listings keep their exchange suffix (Tokyo 6324.T, Hong Kong 0700.HK, Shanghai 600519.SS, Shenzhen 000001.SZ, Taiwan 2330.TW, Korea 000100.KS, Singapore D05.SI, India RELIANCE.NS), but some Japanese and Korean large caps are plain codes (Toyota 7203, Samsung 005930). Either form is resolved automatically when exactly one listing matches; use search_stocks to find a ticker by company name or ISIN."New value: +"Bullrun company ticker, e.g. AAPL, SAP, ABBN or 6324.T. Use the listing ticker returned by search_stocks. US/European examples: AAPL, BMW, NESN. Most Asian listings keep their exchange suffix (6324.T, 0700.HK); some use bare codes (005930). Native or suffixed forms resolve only when one listing matches; search by company name or ISIN if unsure."
  2. Changed1 schema field changedv0.8.1
    • changedInput schema / properties / ticker / description
      Previous value: -"Exact native Bullrun company ticker, e.g. AAPL, SAP or ABBN. Resolve the symbol with search_stocks first if uncertain."New value: +"Bullrun company ticker, e.g. AAPL, SAP, ABBN or 6324.T. Bullrun tickers: US and most European listings use the plain local symbol (AAPL, BMW, NESN, ABBN); most Asian and Indian listings keep their exchange suffix (Tokyo 6324.T, Hong Kong 0700.HK, Shanghai 600519.SS, Shenzhen 000001.SZ, Taiwan 2330.TW, Korea 000100.KS, Singapore D05.SI, India RELIANCE.NS), but some Japanese and Korean large caps are plain codes (Toyota 7203, Samsung 005930). Either form is resolved automatically when exactly one listing matches; use search_stocks to find a ticker by company name or ISIN."
  3. Addedv0.7.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing a real side effect the annotations only imply via readOnlyHint=false: reading news registers demand and triggers a best-effort background refresh that the response does not wait for or confirm. It also bounds the search scope (only newest 50 stored articles) and states the tool does not modify portfolios or place trades, which is exactly the kind of context an agent needs before treating stale output as truth.

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 purpose, scope and ordering, then alternatives, then behavioral caveats. It is dense and long-ish, but every sentence carries operational information (ordering, 50-article cap, refresh behavior, no-write guarantee), with no 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 no output schema, the description still enumerates the returned fields including stored-fetch freshness, and it explains best-effort refresh behavior and the limits of cached/empty results. Nothing an agent needs to call it correctly or interpret an empty response is missing.

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 description coverage is 100%, so ticker syntax, since cutoff semantics and the limit cap are already fully documented in the schema; the description mostly restates 'since cutoff and limit up to 50'. Baseline 3 applies since the schema carries the parameter burden.

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 and resource ('cached company news for one exact Bullrun ticker') plus ordering ('newest publication first') and returned fields (publisher, source URL, date, freshness). It explicitly separates itself from get_corporate_calendar and get_earnings_call_transcript, so an agent can route correctly without opening any schema.

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?

Gives an explicit positive use case ('company headlines and article sources') and names two alternatives with the conditions that select them (scheduled earnings/dividends vs. call text). When-not guidance is also present: cached/empty/stale results do not prove absence of new events.

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