Skip to main content
Glama
Sign In

Company fundamentals by filing date

by io.github.Wei-LienWU
OverviewDiscussionsAdmin

Reported history for a company

get_fundamentals_history
Read-onlyIdempotent

The stored figures for one ticker, one row per metric and period, each with its period (fy, fp), period end, filing date and form. Use it for trends and for what was on file at a past date. Inputs: ticker, metric (comma-separated), from (earliest period end), as_of (only filings dated on or before that day), max_rows (1-250, default 250), compact (true leaves out market_notes and schema). Without a licence key, a company outside the full-history sample answers with its most recent reported fiscal year only: full_history false and history_depth say so, and older filings exist. Long histories are capped at max_rows, keeping the most recent rows of EVERY metric (per_metric says how many of each); metric and from select older rows. Figures are as filed, each keyed to its filing date (filed) as its market records it (how each market dates a filing: https://www.tradingagentapp.com/fundamentals/methodology). .TW quarterly values are already SINGLE-QUARTER amounts, so differencing adjacent quarters gives wrong figures. For a quarterly row (US, Taiwan) fy and fp are the CALENDAR quarter containing the period end, not the company's fiscal quarter. Each reply's market_notes and schema state the per-market caveats (solo or group accounts, lawful gaps, charities, flags in form). Detailed line items follow local accounting rules and keep the filed sign (capex is negative in Taiwan and Japan); get_data_dictionary defines them per market. The source licences require each reply's attribution and licence notices to accompany the figures.

Input Schema

NameRequiredDescriptionDefault
fromNoEarliest period end to include, YYYY-MM-DD
as_ofNoFiling-date cut-off, YYYY-MM-DD: only filings dated on or before that day
metricNoComma-separated metrics, e.g. revenue,net_income
tickerYesTicker symbol, e.g. AAPL or 2330.TW
compactNotrue leaves out the long per-market notes (market_notes, schema) to save tokens; default false
max_rowsNoMost rows to return, 1-250 (default 250); every metric keeps its most recent rows

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / compact
      Added value: +{
+  "description": "true leaves out the long per-market notes (market_notes, schema) to save tokens; default false",
+  "type": "boolean"
+}
    • addedInput schema / properties / max_rows
      Added value: +{
+  "description": "Most rows to return, 1-250 (default 250); every metric keeps its most recent rows",
+  "maximum": 250,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / ticker / maxLength
      Added value: +40
    • addedInput schema / properties / ticker / minLength
      Added value: +1
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare a safe, idempotent, closed-world read; the description goes well beyond them, disclosing the unlicensed-tier limitation (full_history false, truncated to the latest fiscal year), the max_rows truncation contract per metric with per_metric counts, TW single-quarter semantics, calendar-quarter fy/fp for US/Taiwan, signed capex in TW/JP, and the licence obligation to surface attribution and licence notices.

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 purpose and main caveats are front-loaded and nearly every sentence carries real information. It is, however, a single dense block with an 'Inputs: ...' enumeration that partly duplicates the schema, and some market caveats could be delegated to the referenced methodology page.

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, no-output-schema tool with heavy per-market quirks, the description supplies the licensing gate, truncation behavior, row semantics, and legal attribution requirement, and points to the methodology URL and get_data_dictionary for the rest. An agent has enough to call it correctly and interpret the result honestly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns a bump by explaining behavior the schema does not: max_rows keeps the most recent rows of EVERY metric and per_metric reports counts, compact drops market_notes and schema, and as_of filters on filing date rather than period end. It largely restates the input list, so it stops short of 5.

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?

The opening states a concrete resource and shape: 'The stored figures for one ticker, one row per metric and period, each with its period (fy, fp), period end, filing date and form.' It clearly implies the historical counterpart to the live fundamentals tool, but never names get_latest_fundamentals, so differentiation from the sibling relies on inference.

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?

Explicit use cases are given ('Use it for trends and for what was on file at a past date'), plus concrete guidance on when rows are dropped and how metric/from recover older rows. What's missing is a named alternative for point-in-time latest values (get_latest_fundamentals) or a pointer to get_data_dictionary for metric names.

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

All Company fundamentals by filing date toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources