Skip to main content
Glama

Valuein — SEC EDGAR Fundamentals & Smart-Money Data

Financial Ratios

get_financial_ratios
Read-onlyIdempotent

Get pipeline-computed financial ratios from ratio.parquet. Served categories: profitability (margins, ROE, ROA, ROIC), liquidity (current ratio, quick ratio), leverage (D/E, interest coverage, net debt/EBITDA), efficiency (asset turnover, inventory days), per_share (EPS, BVPS, FCF/share), owner_earnings (Buffett FCF, owner yield), valuation (graham_number, ncav_per_share; no price-based multiple is published), and the pipeline-emitted forensic, growth, and rank (cross-sectional *_sector_pctile) categories. NOT every category exists for every ticker — omit categories to get whatever this ticker has, or read available_categories on the DATA_NOT_AVAILABLE_FOR_PERIOD error a missing category returns. valuation is the pair of price-free reference points precomputed at each fiscal period end from SEC filings data. Includes TTM rows alongside annual; each row's is_calendar_aligned is TRUE only when period_end sits on the fiscal-year boundary (±7 days) — filter to TRUE when joining ratios to fact-table fundamentals on (entity, fiscal_year). For historical cuts use as_of_date (PIT by accepted_at when present, else by period_end — see the param). Use this instead of get_valuation_metrics when you only need ratios (no DCF wiring); use get_valuation_metrics when you also need DCF/DDM. Each ratio is a {value, unit, category, reason} entry with a response-level lineage (DerivedLineage) pointing to get_company_fundamentals / verify_fact_lineage for filing-level provenance; a null value carries a reason (e.g. INPUT_MISSING) so missing is never a real zero. An FY ratio also carries a derived_id: cite it like a fact_id (verify_facts re-reads the row). On fiscal-year rows net_debt (total_debt − (cash + short-term investments), the compute_dcf definition), fcf_margin, debt_to_equity (total_debt / equity) and the *_cagr_Ny ratios are recomputed from the annual facts (basis: recomputed_from_facts) so every tool agrees; those carry a formula-form derived_id over the input facts when a registered formula reproduces the figure (net_debt carries none); a CAGR over a zero or negative base is null with a reason. Available on all plans.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>"
    },
    "name": "get_financial_ratios"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of distinct period_end dates to return (1–20). Defaults to 5. Within each period, all matching ratio_names are included.
tickerYesStock ticker symbol, e.g. AAPL, MSFT — or a CIK (SEC identifier), e.g. '0000320193'.
as_of_dateNoHistorical cutoff (canonical cross-tool date param). PIT by SEC accepted_at when the ratio data carries it (latest value knowable on/before the date, zero look-ahead, _meta.pit_safe=true), else by ratio.period_end (pit_safe=false). For guaranteed accepted_at PIT use get_company_fundamentals.
categoriesNoRatio categories to include (see the enum). Omit to return every category this ticker has. `valuation` (graham_number, ncav_per_share) are precomputed at each fiscal period end. Availability is per-ticker (the envelope lists this ticker's available_categories).
fiscal_periodNoFilter to a specific fiscal period type. Use 'TTM' for trailing twelve months. Omit to return both annual (FY) and TTM rows.
period_end_beforeNoAlias of as_of_date (as_of_date preferred — the canonical name). Returns ratios with period_end on or before this date.

Output Schema

NameRequiredDescriptionDefault
dataYes
noteYes
planYes
_metaYesProvenance envelope — data lineage for every MCP response
tickerYes
lineageNoProvenance for pipeline-derived values (ratio.parquet / factor_scores.parquet): source table + pipeline computed_at, plus a pointer to the tools that return filing-level lineage. NOT point-in-time (recomputed on each pipeline run).
periods_returnedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / categories / description
      Previous value: -"Ratio categories to include (see the enum). Omit to return every category this ticker has. `valuation` (pe_ratio, pb_ratio, ev_ebitda, market_cap, dividend_yield) are precomputed at each fiscal period end. Availability is per-ticker (the envelope lists this ticker's available_categories)."New value: +"Ratio categories to include (see the enum). Omit to return every category this ticker has. `valuation` (graham_number, ncav_per_share) are precomputed at each fiscal period end. Availability is per-ticker (the envelope lists this ticker's available_categories)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / categories / description
      Previous value: -"Ratio categories to include (see the enum). Omit to return every category this ticker has. `valuation` (pe_ratio, pb_ratio, ev_ebitda, market_cap, dividend_yield) is LIVE since schema 2.18.0 — price-derived, period-end-aligned, not strictly PIT. Availability is per-ticker (the envelope lists this ticker's available_categories)."New value: +"Ratio categories to include (see the enum). Omit to return every category this ticker has. `valuation` (pe_ratio, pb_ratio, ev_ebitda, market_cap, dividend_yield) are precomputed at each fiscal period end. Availability is per-ticker (the envelope lists this ticker's available_categories)."
    • removedOutput schema / properties / _meta / properties / price_as_of
      Removed value: -{
      -  "description": "ISO timestamp when the price surfaces were last refreshed.",
      -  "type": "string"
      -}
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond them: null values always carry a `reason` so 'missing is never a real zero', FY rows carry a `derived_id` citable like a fact_id, response-level `lineage` points to provenance tools, and specific ratios are recomputed from annual facts under `basis: recomputed_from_facts`. It also discloses the zero/negative-base CAGR null case and that the tool is available on all plans.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and sibling routing are correctly front-loaded, and every clause carries real information, but the body is a dense multi-topic run-on built from semicolons, em-dashes, and parentheticals mixing category inventory, error handling, lineage, and recomputation caveats. It would scan far better split into short labeled blocks (Returns / When to use / Caveats).

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?

For a six-parameter tool with an output schema, this is complete: it covers error paths, PIT look-ahead behavior, null-with-reason semantics, provenance tools, and the recomputation caveats that would otherwise cause silent disagreement between tools. Nothing an agent needs in order to call it correctly appears to be 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 the baseline is 3. The description largely restates what the schema already says (omit `categories` to get all available, as_of_date PIT semantics, TTM vs annual). Its only genuine additions over the schema are the error-driven way to discover available categories and the period_end_before/as_of_date preference, which are modest.

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 names a specific verb and resource ('Get pipeline-computed financial ratios from ratio.parquet') and then enumerates the served categories with concrete examples (margins, ROE, ROIC, graham_number, ncav_per_share). It explicitly differentiates itself from the closest sibling, get_valuation_metrics, so an agent can choose between them without opening either 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?

It states both sides of the routing decision: 'Use this *instead of* get_valuation_metrics when you only need ratios (no DCF wiring); use get_valuation_metrics when you also need DCF/DDM.' It also gives operational guidance for missing categories (omit `categories`, or read `available_categories` off the DATA_NOT_AVAILABLE_FOR_PERIOD error), for joining (filter `is_calendar_aligned` to TRUE on entity/fiscal_year), and for guaranteed PIT (use get_company_fundamentals).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.