Skip to main content
Glama

Get revenue breakdown

get_revenue_breakdown
Read-only

Fetch segment, geography, product, or customer revenue breakdown rows for an exact Bullrun ticker to separate cyclical from recurring revenue and inspect geographic exposure.

Instructions

Fetch segment, geography, product, customer, or other revenue breakdown rows for one exact Bullrun ticker. Use this to separate cyclical businesses from recurring segments or inspect geographic exposure instead of relying on blended revenue. Read-only.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum breakdown rows to return.
tickerYesThe Bullrun ticker, e.g. "SPGI", "MSFT", "V". 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.
dimensionNoBreakdown dimension to return, or all dimensions.all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.0
    • changedInput schema / properties / ticker / description
      Previous value: -"The Bullrun ticker, e.g. \"SPGI\", \"MSFT\", \"V\". 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: +"The Bullrun ticker, e.g. \"SPGI\", \"MSFT\", \"V\". 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.7.0
    • changedInput schema / properties / ticker / description
      Previous value: -"The ticker exactly as listed on Bullrun, e.g. \"SPGI\", \"MSFT\", \"V\"."New value: +"The Bullrun ticker, e.g. \"SPGI\", \"MSFT\", \"V\". 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. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description's 'Read-only' merely restates that. The only added behavioral signal is that a single 'exact' ticker scopes the call, with nothing about result shape, periodicity, or how missing breakdown data is handled.

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?

Two sentences, front-loaded with what it fetches, followed by the analytical motivation. The trailing 'Read-only.' is a fragment that only duplicates the annotations and is slight waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter read tool with full schema coverage, the core is covered, but there is no output schema and the description never indicates what a breakdown row contains (values, period, currency, hierarchy). An agent still can't tell what it will get back.

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%, with clearly documented ticker, dimension enum, and limit. The description echoes the dimension list and the 'one exact ticker' constraint but adds no format or semantics beyond the schema, so the baseline of 3 applies.

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 verb (fetch) and resource (revenue breakdown rows) and enumerates the dimensions available, so an agent can tell it apart from a blended-revenue or KPI tool. It does not name a specific sibling, so the differentiation is conceptual rather than explicit.

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?

'Use this to separate cyclical businesses from recurring segments or inspect geographic exposure instead of relying on blended revenue' gives a clear positive trigger and implicitly steers away from blended-revenue tools. No when-not-to-use or prerequisite conditions are stated.

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