Skip to main content
Glama

Financials

financials
Read-only

⭐ Company FINANCIAL STATEMENTS — income / balance / cash-flow + auto-detected abnormality signals. Read ONE company or COMPARE up to 8 (revenue, growth, margins, ROE, FCF…), on a clean normalized feed uniform across every industry (banks, insurers, REITs). 🔴 To compare SEVERAL, pass them ALL in ONE call (tickers='TSLA.US,MSFT.US') — a single call aligns them on a common basis+currency and costs a fraction of N calls. Pick ONE period (quarterly already carries YoY). 🎚 fields: leave EMPTY for the DIGEST (small default — headline + ratios + capital-return + signals; covers most compares); set it for specific line items, a whole statement ('income'|'balance'|'cashflow'), or 'all'. ⏱ period = the window (5y / 2022 / 2022-2023 / 5q / 2024Q2), mapped to each fiscal year. 🌐 currency=USD (auto for multi-company) converts totals at each period's date. 🗣 The digest carries a plain read (facts, not advice) and may carry _notes (per-period comparability flags — the warning is FACT, each likely_causes is an inferred lead to VERIFY). 📏 LIMITS: ≤8 companies · ≤20 fields · ~4–5y history. A non-equity/unlisted entry → ok:false. 🔴 pulse(kind='asset') on a stock ALREADY embeds this digest — call financials only for a dedicated read/compare or a specific fields/statement pull, not right after pulse(kind='asset').

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": {
      "tickers": "<tickers>"
    },
    "name": "financials"
  }
}

Input Schema

NameRequiredDescriptionDefault
fieldsNoOPTIONAL — the granularity dial. LEAVE EMPTY for the DIGEST (headline + ratios ROE/ROA/margins/debt/current/quick + capital-return dividends/buybacks + abnormality signals) — the safe default that already answers most reads/compares. Set it ONLY for a specific LINE ITEM the digest lacks. Comma-separated / a list. 🆕 EACH entry can be EITHER an exact key OR a plain-English description — the SERVER resolves it for you (no need to know the exact key, no separate resolver call): • exact key if you know it → used directly (fast): revenue, cost_of_revenue, gross_profit, operating_income, ebit, ebitda, net_income, total_assets, current_assets, cash, inventory, receivables, net_ppe, goodwill, intangibles, total_liabilities, current_debt, long_term_debt, total_debt, total_equity, retained_earnings, operating_cash_flow, free_cash_flow, capex, dividends_paid, buybacks, … (BANK/INSURANCE lines too). • don't know the key? just DESCRIBE the line — 🔴 in ENGLISH (translate first: ค่าความนิยม→'goodwill', 投資不動産→'investment properties') — e.g. 'construction in progress', 'held-to-maturity securities', 'accrued interest receivable'. Loose/approximate English is fine (the server matches meaning). • 'income' | 'balance' | 'cashflow' → that WHOLE statement · 'all' → every reported line (large). 🔴 If a term is AMBIGUOUS or NOT a financial-statement line, the tool returns `needs_confirmation` — follow its `_guide`/`note` (pick from candidates and re-call, or tell the user it's unavailable). Unreported-but-valid line → empty/`unavailable_fields`; state absences plainly, never fabricate. NOTE: ratios/multiples (ROE, P/E) live in the DIGEST, not here.
periodNoOPTIONAL time selector, mapped to each company's FISCAL year. Forms: '5' or '5y' = last 5 years (default 5) · '2022' = that fiscal year · '2022-2023' = a range · '2020,2022' = specific years · '5q' = last 5 quarters · '2024Q2' = one quarter · 'quarterly' = latest quarters. History reaches ~4–5 years back — an older specific year may be unavailable (the server says so).
contextNoOPTIONAL but RECOMMENDED — paste the user's FULL request VERBATIM (any language: 'ขอราคาผลไม้ apple', 'compare Apple and Microsoft stock'). The server uses it to disambiguate which candidate each `ticker` entity means (the apple COMPANY vs the fruit COMMODITY; which Samsung). One context per call, shared by all tickers here.
tickersYes1–8 comma-separated COMMON-STOCK companies to read/compare financial statements for. EACH entry can be EITHER an exact Ava Advisor ticker ('AAPL.US', '2330.TW') — used directly — OR a bare symbol / company name ('AAPL', 'Apple', 'トヨタ') which the SERVER resolves for you (no separate lookup step). 🔴 If an entry is AMBIGUOUS (same name/symbol across markets or entities) or is NOT a company, the tool returns `needs_confirmation` — follow its `_guide`. NOT for ETF/commodity/bond/crypto — no company financials.
currencyNoConvert ABSOLUTE totals to this currency (e.g. USD) at each period's date so cross-currency companies compare — margins/growth are currency-neutral anyway. A multi-company compare defaults to USD.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With only readOnlyHint=true supplied, the description carries the burden well: it discloses hard limits (≤8 companies, ≤20 fields, ~4–5y history), the `ok:false` failure mode for non-equity/unlisted entries, currency conversion at each period's date, and the fact that `_notes` comparability warnings are facts while `likely_causes` are inferred leads to verify. That is material behavioral context absent from the annotations.

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?

Front-loaded and sectioned with labeled bullets (🔴/🎚/⏱/🌐/📏), but it is dense with emoji and duplicates a large share of the already-rich parameter descriptions in the schema. The key routing rule (don't call after pulse) sits at the very end rather than up top.

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 5-parameter comparison tool with no output schema, the description covers inputs, limits, error/confirmation states, and the shape of the digest return (headline, ratios, capital-return, signals, `read`, `_notes`). 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% and the schema already spells out `fields` (exact key vs plain-English resolution, statement shortcuts), `period` forms, `context`, and `currency`. The description largely restates that material, adding only marginal framing such as 'pick ONE period (quarterly already carries YoY)'. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Company FINANCIAL STATEMENTS — income / balance / cash-flow') plus the two operating modes (read ONE vs COMPARE up to 8), and explicitly distinguishes itself from the sibling pulse(kind='asset'), which already embeds this digest. An agent can identify the tool without opening the 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 explicit when-to-use routing: pass all tickers in ONE call rather than N calls, leave `fields` empty for the digest unless a specific line item is needed, and skip this tool right after pulse(kind='asset'). It also names the exclusion (not for ETF/commodity/bond/crypto) and the ambiguity path (`needs_confirmation`).

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.