Skip to main content
Glama

Valuein — SEC EDGAR Fundamentals & Smart-Money Data

by io.github.valuein

Company Fundamentals

get_company_fundamentals
Read-onlyIdempotent

Retrieve standardized SEC EDGAR fundamental financial metrics for a US public company. Returns revenue, gross profit, operating income, net income, EPS (diluted), total assets, total liabilities, stockholders' equity, cash & equivalents, total debt, operating cash flow, and capital expenditures for one or more fiscal periods. Data sourced from 10-K (annual) and 10-Q (quarterly) filings. Point-in-time: no look-ahead bias — pass as_of_date (YYYY-MM-DD) to reconstruct exactly the information set known on that date. This returns the raw as-reported line items ONLY. Do NOT derive metrics from them yourself — a hand-computed figure carries no fact_id and cannot be verified against a filing. Every derived metric is already served pre-computed WITH provenance: free cash flow, FCF margin, margins, ROE/ROA/ROIC, leverage and the price multiples come from get_valuation_metrics; the full ratio table (incl. per-share, owner-earnings, growth) from get_financial_ratios; intrinsic value from compute_dcf. If one of those is gated on your plan, say so and offer the upgrade — never substitute your own arithmetic.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of periods to return (1–40). Defaults to 5.
periodNoFiling period granularity. Annual uses 10-K; quarterly uses 10-Q.annual
strictNoWhen true, fail with PLAN_LIMIT_EXCEEDED if the plan cannot satisfy the requested limit. Default false: return what's available and explain the gap in _meta.truncation.
tickerYesStock ticker symbol, e.g. AAPL, MSFT, BRK.B
as_of_dateNoPoint-in-time date (YYYY-MM-DD). Only returns facts with accepted_at on or before this date — eliminates look-ahead bias for backtesting. Omit for the full dataset.
fiscal_yearNoFiscal year (YYYY). Omit to return the most recent available years.
lineage_detailNoPer-period provenance envelope + per-metric availability/provenance sidecars. 'compact' (default) returns source_filing + source_url (the SEC Inline-XBRL viewer with every tagged fact highlighted when the filing is iXBRL, else the rendered document, else the filing index) + sec_url/document_url/inline_viewer_url + restated flag, plus lean per-metric availability + fact_id + source_filing. 'full' adds first_filed_at + accepted_at + per-metric source_url + computed inputs[]. 'off' omits all provenance.compact
min_confidenceNoWithhold any metric whose backing fact scores below this confidence [0, 1]. The score is a PENALTY FROM EVIDENCE — every fact starts at 1.0 and is docked only for something checkable: a failed accounting identity (-0.40), a later filing that revised the number (-0.20), an unaudited filing (-0.05). It is NOT a function of age: a clean 1995 fact scores the same as a clean 2026 one. Guide: 0.95 = 'no evidence against this number' (the normal case — ~99.9% of facts, every year); 0.80 = tolerate a fact a later filing revised; 0.60 = tolerate a filing whose accounting identities failed. A withheld metric is reported as availability:'suppressed' — never dropped silently, and never as 'not_reported', which would claim the company did not file it. Facts with no confidence score are withheld too (fail closed).
response_formatNoOutput shape. 'flat' (default) returns the legacy `metrics` object plus the additive `metrics_availability`/`metrics_provenance`/`metrics_display` sidecars — `metrics_display` holds each figure already rendered for prose ("$402.83B"), and you should quote it verbatim rather than reformatting `metrics` yourself. 'envelope' additionally attaches `metric_envelopes` — one canonical {metric,value,unit,scale,period,availability,provenance,display} object per metric. Both shapes carry the same display strings.flat

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
_metaYesProvenance envelope — data lineage for every MCP response
periodYes
tickerYes
as_of_dateYes
company_nameYes
years_returnedYes

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses that results are raw as-reported line items only, sourced from 10-K/10-Q filings, and point-in-time with no look-ahead bias. It also reveals provenance behavior, confidence-based suppression, and plan-gating handling, all of which add meaningful behavioral context beyond annotations.

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 dense and front-loaded with the main purpose, followed by important caveats and alternative routing. It is longer than a minimal description, but given 9 parameters and the need to prevent manual derivation, most sentences earn their place; a small amount of repetition around 'raw only' and 'never substitute your own arithmetic' keeps it from a 5.

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 9-parameter tool with an output schema, the description covers the core semantics, data source, point-in-time behavior, raw-only contract, and sibling-tool routing. The output schema handles return-value details, so the description is fully sufficient for an agent to select and invoke the tool correctly.

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?

All nine parameters already have rich schema descriptions (100% coverage), so the baseline is 3. The description references as_of_date and mentions 10-K/10-Q sourcing, but it does not materially add semantics beyond what the schema already provides.

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 opens with a specific verb and resource: 'Retrieve standardized SEC EDGAR fundamental financial metrics for a US public company.' It enumerates the exact metrics returned and explicitly distinguishes itself from sibling tools such as get_valuation_metrics, get_financial_ratios, and compute_dcf by clarifying that it serves raw as-reported line items only.

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?

The description gives explicit when-to-use guidance by naming alternatives: derived metrics come from get_valuation_metrics, the ratio table from get_financial_ratios, and intrinsic value from compute_dcf. It also instructs the agent to say so and offer the upgrade if those are plan-gated, rather than substituting manual arithmetic.

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

All Valuein — SEC EDGAR Fundamentals & Smart-Money Data toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool has a distinct purpose with detailed descriptions that clarify differences. Overlaps like get_peer_comparables vs screen_universe are well-differentiated by scope (single company vs cross-sectional). Similarly, get_insider_sentiment vs get_smart_money_flow are clearly distinguished by data sources and methodology.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., create_report, get_financial_ratios, delete_alert). No mixing of conventions or inconsistent verbs.

Tool Count2/5

With 69 tools, the count far exceeds the 25+ threshold for 'too many'. While the domain is broad, the sheer volume likely overwhelms agents and increases selection complexity.

Completeness4/5

The tool set covers a wide range of SEC filings, ratios, smart-money data, alerts, reports, and more. Minor gaps exist (e.g., no options or detailed debt data), but most analyst workflows are supported.

Resources