Skip to main content
Glama
Sign In
Bullrun

Bullrun

by ferinator
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get company risk history and changes

get_company_risk_history
Read-only

Retrieve stored historical company risk category scores and observed input changes to see how a company's risk changed and which inputs changed.

Instructions

Stored historical company risk category readings and their observed input changes. Shows dates, computation times, formula versions, score changes, changing input coverage and measurement bases. Use for 'how has X's risk changed?' and 'which inputs changed?'. These are retained category scores, not a complete daily series or proof of causation. Missing history is unknown, never a zero risk score. Read-only; does not run risk computation or paid discovery.

Input Schema

NameRequiredDescriptionDefault
limitNoLatest stored run dates to return, oldest first; each date carries its change from the previous stored date. Retention and gaps vary. Full detail supports at most six dates.
detailNoSummary keeps scores, explanations and up to three changed inputs per category; full includes stored input terms and all returned term changes.summary
tickerYesBullrun company ticker, e.g. AAPL, SAP 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 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 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. Changed3 schema fields changedv0.8.1
    • changedInput schema / properties / limit / default
      Previous value: -6New value: +3
    • changedInput schema / properties / limit / description
      Previous value: -"Latest stored run dates to return, oldest first. Retention and gaps vary. Full detail supports at most six dates."New value: +"Latest stored run dates to return, oldest first; each date carries its change from the previous stored date. Retention and gaps vary. Full detail supports at most six dates."
    • changedInput schema / properties / ticker / description
      Previous value: -"Exact native Bullrun company ticker, e.g. AAPL or SAP."New value: +"Bullrun company ticker, e.g. AAPL, SAP 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.4/5.0
Behavior5/5

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

With annotations already covering read-only and closed-world, the description still adds substantive semantics: missing history means unknown rather than zero risk, gaps and retention vary, scores are not proof of causation. These are interpretation rules an agent cannot get from the annotations or 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?

Front-loaded with what is returned, then usage, then caveats, then safety in four dense sentences. The mid-sentence enumeration ('changing input coverage and measurement bases') is slightly packed but every sentence carries information.

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?

There is no output schema, so the description carries the burden of describing results, and it does: dates, computation times, formula versions, score changes, changed inputs. Combined with the missing-data caveat, an agent knows enough to call and interpret it correctly.

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 coverage is 100% and the schema already explains limit (latest stored run dates, max 30), detail (summary vs full), and ticker formats. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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 ('Stored historical company risk category readings and their observed input changes') and enumerates what the payload contains (dates, computation times, formula versions, score changes). It distinguishes itself from the current-state and timeseries siblings by explicitly saying these are retained category scores, not a complete daily 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?

Names the exact user questions this answers ('how has X's risk changed?', 'which inputs changed?') and gives an exclusion ('does not run risk computation or paid discovery'). It stops short of naming the alternatives, e.g. get_company_risk for the current reading or get_risk_movers for cross-company movers, so routing between siblings still requires inference.

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