Skip to main content
Glama

Get operating KPIs

get_operating_kpis
Read-only

Retrieve stored operating KPI observations and source links for a specific Bullrun ticker, including fiscal periods and units; check coverage first because availability is sparse.

Instructions

Read curated, source-linked operating KPI observations for one exact Bullrun ticker. Coverage is sparse and no automatic KPI feed is configured: do not assume ARR, retention, customer counts or payments metrics are available. Check get_company_data_coverage first. Returns stored fiscal periods, units and source links; company-economics observations are a separate dataset. Read-only.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum KPI rows to return.
tickerYesBullrun ticker, e.g. "CRWD", "SNOW", "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.
categoryNoOptional category filter such as SaaS, payments, marketplace, banking, or other domain labels.
metricKeyNoOptional metric key present in stored coverage. No particular business KPI is guaranteed to be available.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.1
    • changedInput schema / properties / ticker / description
      Previous value: -"The ticker exactly as listed on Bullrun, e.g. \"CRWD\", \"SNOW\", \"V\"."New value: +"Bullrun ticker, e.g. \"CRWD\", \"SNOW\", \"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."
  2. Changed1 schema field changedv0.7.0
    • changedInput schema / properties / metricKey / description
      Previous value: -"Optional exact metric key to filter, e.g. ARR, NRR, RPO, BILLINGS, PAYMENT_VOLUME."New value: +"Optional metric key present in stored coverage. No particular business KPI is guaranteed to be available."
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: coverage is sparse, no automatic KPI feed is configured, specific metrics should not be assumed available, and the return shape includes stored fiscal periods, units and source links. These details directly affect whether and how an agent invokes the tool.

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?

The description is front-loaded with purpose, then coverage caveats, then return details. It is efficient, though the final 'Read-only' repeats the annotation and the coverage warnings are slightly redundant with the 'do not assume' sentence.

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?

Given the absence of an output schema, the description supplies the key return-context details (fiscal periods, units, source links). It also covers the main risk — sparse coverage — and tells the agent to check coverage first, which is exactly what is needed for correct use.

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 all four parameters are fully documented in the input schema. The description only broadly mentions 'one exact Bullrun ticker' and does not add syntax or filtering guidance beyond what the schema already provides, making the baseline 3 appropriate.

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 description states a precise verb and resource — 'Read curated, source-linked operating KPI observations for one exact Bullrun ticker' — and distinguishes the dataset from company-economics observations. An agent can immediately tell what this tool returns and how it differs from related data tools.

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 a clear prerequisite ('Check get_company_data_coverage first') and explicit warnings about what not to expect ('do not assume ARR, retention, customer counts or payments metrics are available'). It does not name a specific alternative tool for company-economics observations, but the routing guidance is strong.

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