Skip to main content
Glama
edgar-search-mcp

edgar-search-mcp

by jibarix

get_filing_xbrl

Read-only

Retrieve one XBRL part of an SEC filing at a time—summary, schema, linkbases, or instance—to inspect the filer's exact disclosures and facts.

Instructions

The XBRL files of one filing as the filer wrote them, one part at a time.

The filing is accession_number, else the first row of the company's submissions, in the SEC's order, whose form equals form exactly (of any form when form is None, the default); with as_of (YYYY-MM-DD) only rows whose filingDate is on or before it, and a row without such a date is skipped and named in warnings, never taken as earlier.

  • "summary": the submissions row, the acceptance time as the filing header states it, the instance and schema files and how each was found, and the SEC's FilingSummary.xml as an element tree (null, and named in unresolved, when the folder has none).

  • "schema": the declarations of the company schema and of every schema of the filing reached from it, the instance or their linkbases (the same files whatever the part), file by file, in document order: imports, linkbase references, role and arcrole types (definition and usedOn as written) and elements with every attribute. Imported schemas outside the filing are listed in unresolved.

  • "presentation", "calculation", "definition", "label", "reference": the extended links of that element in every linkbase of the filing that the schemas or the instance reference (link:linkbaseRef) or that a schema contains, including schemas found only through a locator, roleRef or arcroleRef of another part's link, flattened in document order to locators, arcs and resources. Every file is read once; one not read is in unresolved. Every attribute is kept (order, weight, priority, use="prohibited", preferredLabel, xml:lang, ...); no arc is combined, overridden or dropped, and no label or language is preferred. A locator's target is the element of a filing schema its href names, or unresolved with the reason (a schema outside the filing, say).

  • "instance": the instance in document order: contexts (entity identifier and scheme, period as written, explicit members, typed members as XML), units and facts (concept as namespace URI and local name, contextRef, unitRef, decimals, precision, xsi:nil, the text as written). Every duplicate is returned; none is chosen.

concepts (with "instance", up to 50) keeps the facts of the named concepts and the contexts and units they use. A name is "prefix:local" (prefix resolved through the instance's own declarations), "{namespace}local", or a bare local name, which matches that local name in every namespace; concept_matches says what each name matched. A fact inside a tuple is found too and has path; a name of an element that is no fact (a tuple) is listed as unsupported and in unresolved. Items are paged by offset and limit; page.next_offset is null on the last page. Attribute names in a namespace are given as "{namespace}local". Each file parsed comes with its document element (root) and namespace declarations; not_returned lists what the response leaves out of it.

Files are found only from what the filing publishes: the instance is the one row of the filing index page typed EX-101.INS or described as the extracted XBRL instance; the schema is the one the instance's link:schemaRef names. Zero or several candidates leave a file unresolved with the candidates listed; instance_file and schema_file (a file name in the filing folder) then name it.

Input Schema

NameRequiredDescriptionDefault
formNo
partNosummary
as_ofNo
limitNo
offsetNo
conceptsNo
schema_fileNo
cik_or_tickerYes
instance_fileNo
accession_numberNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only annotation, the description discloses fallback filing selection, unresolved-file handling, warnings, duplicate fact preservation, no arc combination, paging behavior, and the fact that files are found only from what the filing publishes. These are substantive behavioral traits an agent needs before invoking the tool.

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 and dense, but it is front-loaded with the core purpose and then organized by selection logic, parts, concept filtering, and file discovery. The length is largely justified by the tool's complexity, though some sentences could be more scannable.

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?

Given a 10-parameter tool with complex XBRL part semantics, the description covers filing selection, part behavior, concept filtering, paging, unresolved candidates, and file discovery. Because an output schema exists, it does not need to explain return values, but its extra return-shape details are still coherent and helpful.

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?

With 0% schema description coverage across 10 parameters, the description compensates extensively by defining `part` modes, `concepts` naming formats, paging via `offset`/`limit`, and the roles of `accession_number`, `form`, `as_of`, `instance_file`, and `schema_file`. It leaves `cik_or_ticker` implicit and does not state limit bounds or default behavior, so it is strong but not exhaustive.

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 description states a specific resource, the XBRL files of one filing as the filer wrote them, and a specific access pattern, one `part` at a time. It is clearly distinct from document/text siblings, but it does not explicitly name or contrast those siblings.

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?

It gives detailed guidance on selecting the filing via `accession_number`, `form`, and `as_of`, and explains what each `part` returns. It does not explicitly state when not to use this tool or name alternative sibling tools for non-XBRL needs.

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