Skip to main content
Glama
pgeneralpl

edgar-entity-mcp

by pgeneralpl

Normalized financials (XBRL)

get_financials
Read-onlyIdempotent

Retrieve normalized SEC XBRL financial metrics for a company by ticker, CIK, or name, one row per fiscal period, annual or quarterly.

Instructions

Key financial metrics normalized from SEC XBRL companyfacts, one row per fiscal period (deduped; as-filed values from the filing that reported the period). Metrics: revenue, gross_profit, operating_income, net_income, eps_basic, eps_diluted, operating_cash_flow, capex, total_assets, total_liabilities, stockholders_equity, cash, long_term_debt, shares_outstanding, free_cash_flow (derived). Revenue tries common tags in order (Revenues, RevenueFromContractWithCustomerExcludingAssessedTax, SalesRevenueNet, ...) and tags_used reports which was used. period_type 'quarterly' returns 3-month values (cash-flow quarters derived from YTD; Q4 derived as FY minus 9M). Values are raw (e.g. 391035000000 = $391.0B).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of most recent periods
companyYesTicker (AAPL), CIK (320193 or 0000320193), or company name. Names must resolve unambiguously; use search_company first if unsure.
metricsNoSubset of metrics to return (default all)
period_typeNoannual

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is low, yet the description adds substantial unsurfaced behavior: dedup policy, 'as-filed values from the filing that reported the period', the ordered tag-fallback chain with tags_used reporting, and the quarterly derivation rules (cash-flow quarters from YTD; Q4 = FY minus 9M).

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?

Dense but nearly every clause carries unique information; purpose and grain are front-loaded. It reads as one long block rather than separated sentences, which slightly hurts scannability of the derivation rules.

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?

No output schema exists, and the description discharges that burden by naming the returned fields (tags_used), the row grain, the value units, and the period derivation logic. Nothing an agent needs to interpret the result is missing.

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

Parameters5/5

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

Schema coverage is 75% and the description compensates where it matters most: it explains period_type='quarterly' semantics in depth (derived 3-month values, Q4 derivation) and clarifies raw value scaling (391035000000 = $391.0B), which the schema does not state anywhere.

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 ('Key financial metrics normalized from SEC XBRL companyfacts'), enumerates the exact 15 metrics returned, and pins the row grain ('one row per fiscal period'). The 'normalized' framing implicitly separates it from the raw-concept sibling get_xbrl_concept, so an agent can route without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the tag-fallback and quarterly-derivation notes tell the agent what to expect, but there is no explicit statement of when to pick this over get_xbrl_concept or compare_companies, and no exclusions (e.g. non-XBRL filers, foreign issuers).

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