Skip to main content
Glama

Query line items by name

query_line_items
Read-onlyIdempotent

Fetch XBRL facts for a single filing by line-item name (e.g. revenue, net income, operating expenses). Identify the filing with filing_id, OR with ticker + fiscal_year (+ optional quarter). line_items: non-empty list of names; resolved through L0-L3 tiers. Each result carries _resolution_level ("L0"-"L3") showing which tier matched; L0-L3 cost 10 / 20 / 30 / 50 credits per line item, itemised in credits_by_line_item. form_type defaults to 10-K — for foreign issuers pass 20-F or 40-F; Korean (DART) filings use 10-K / 10-Q. Returns consolidated totals only — dimension slices (a single product line, segment, or region) are not served here, even when a printed statement row carries that name. By default each result lists its dimensional_breakdowns and a _warnings entry names the results that have them. To get slice values: get_dimensional_breakdown_by_fact_id (from the total's fact_id) / get_dimensional_breakdown_by_line_item, or get_filing_statement to read the full statement table. light_weight_mode=true (bool, default false) omits results[*].dimensional_breakdowns — saves context when you already know exactly what you need. Charged identically. A result may appear at multiple positions in the source filing; fact_ids lists every position as {fact_id, source_locator} pairs. If unsure of a line item name or fact_id, use list_filing_statements / get_filing_statement to read the whole statement. Multi-concept matches come pre-ordered (Akkru smart ranking); the order is a recommendation only — review all returned results and judge which one you need. To fetch by fact_id use get_filing_facts. POST /api/v1/data/line-items; see FINANCIAL_API_DOCUMENTATION.md.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tickerNoCompany ticker, e.g. "AAPL" (US), "000100" (Korea), "1332" (Japan), "VIRI_F" (Europe), "600519_CN" (China A-share). Use with fiscal_year when filing_id is omitted.
quarterNoQuarter label, e.g. "Q1"–"Q4" or "FY". Only needed to disambiguate quarterly filings.
filing_idNoNumeric filing id (from list_filings). Provide either filing_id, or ticker + fiscal_year.
form_typeNoFiling form. US: "10-K" / "10-Q"; foreign annual: "20-F" / "40-F"; Korean (DART): "10-K" (annual) / "10-Q" (quarterly). Defaults to "10-K".10-K
line_itemsYesLine-item names to fetch, e.g. ["revenue", "net income"] (1–50; each ≤ 256 chars).
fiscal_yearNoReporting fiscal year (1990–2100). Required together with ticker when filing_id is omitted.
light_weight_modeNoWhen true, return a leaner payload (drops the most verbose nested fields). Charged the same. Saves context when you already know exactly what you need.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses per-tier credit costs (10/20/30/50), the presence of `_resolution_level`, consolidated-totals-only behavior, multi-position fact_ids, smart ranking behavior, and the payload effect of light_weight_mode. These are substantive behavioral details not visible in annotations or schema.

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 long but densely packed with operationally relevant details, and the most important scoping constraints (single filing, consolidated totals only) appear early. A few points are repeated or elaborated more than strictly necessary, but overall each sentence contributes to correct invocation.

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?

With no output schema, the description compensates by explaining result structure (`_resolution_level`, credits_by_line_item, dimensional_breakdowns, _warnings, fact_ids), limitations, pricing, mode options, and alternative tools. An agent has enough context to call this correctly and know what to expect.

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 the baseline is 3. The description adds meaningful semantics beyond the schema: line-items resolved through L0-L3 tiers, per-line-item cost breakdowns, the exact payload effect of light_weight_mode, and form_type nuances for foreign/Korean filings. This elevates it above the baseline but does not radically expand every parameter.

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 states a specific verb and resource: 'Fetch XBRL facts for a single filing by line-item name'. It immediately distinguishes itself from siblings by naming alternatives like get_filing_facts, get_filing_statement, and get_dimensional_breakdown_by_line_item, and by clarifying that only consolidated totals are returned.

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 routing guidance: use get_dimensional_breakdown_by_fact_id/get_dimensional_breakdown_by_line_item for slices, use list_filing_statements/get_filing_statement when unsure of names, and use get_filing_facts when fetching by fact_id. It also clearly states a negative condition: dimension slices are not served here.

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.

Resources