edgar-mcp

Overview Schema Source Related Servers Discussions Admin

get_filing_section

Extract a targeted narrative section from SEC filings by CIK and accession number: Risk Factors, MD&A, legal proceedings, to answer questions about disclosed risks and management commentary.

Instructions

Read one named section out of a filing's text, e.g. Risk Factors or MD&A.

Use this for narrative questions — what management said about demand, what risks the company discloses, what a legal proceeding is about. Do not use it to read financial figures: use get_financial_concept, which returns tagged numbers rather than text that used to be a table.

Get the accession number from list_filings first.

Sections this tool can extract, by key: business (Item 1), risk_factors (Item 1A), properties (Item 2), legal_proceedings (Item 3), mda (Item 7), market_risk (Item 7A), financial_statements (Item 8), controls (Item 9A).

Section boundaries are found by matching item headings in the flattened document. This works well for 10-K and 10-Q filings from roughly 2005 onward. It works less well on older filings, on filings that incorporate a section by reference to an exhibit or a proxy statement, and on filings that use unusual heading formats. When the section cannot be found the tool says so and gives you the document URL — pass that URL to the user rather than describing the section from memory.

Long sections are truncated. Check truncated and say so if you summarise.

Args: cik: The company's CIK, from resolve_company. accession_number: The filing's accession number from list_filings, in the form 0001045810-24-000029. section: A section key such as "risk_factors", or an alias such as "Item 1A" or "MD&A". max_chars: Maximum characters of section text to return. Default 20000.

Returns: text, section_label, form, filing_date, period_of_report, document_url, chars_returned, truncated, and extraction_confidence.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`cik`	Yes
`section`	Yes
`max_chars`	No
`accession_number`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 9, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals section-boundary matching by item headings, notes where extraction works less well, explains failure behavior including returning the document URL, and discloses that long sections are truncated and that the `truncated` flag should be checked.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense, and every section earns its place: purpose, usage guidance, section keys, extraction limitations, truncation warning, and parameter/return documentation. It is front-loaded with the core purpose and immediately actionable guidance.

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 tool with no annotations and zero schema-description coverage, this description is remarkably complete. It gives an agent everything needed to call the tool correctly: prerequisites, parameter meanings, supported sections, limitations, truncation behavior, and failure handling—without needing to infer from the schema.

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 description coverage is 0%, so the description must compensate, and it does. Each parameter is explained with provenance or format: cik comes from resolve_company, accession_number has an explicit example format, section accepts keys or aliases like 'Item 1A' or 'MD&A', and max_chars has a default and meaning.

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: 'Read one named section out of a filing's text.' It gives concrete examples (Risk Factors, MD&A) and distinguishes itself from get_financial_concept by clarifying that this tool handles narrative text rather than tagged financial figures.

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?

It explicitly says when to use the tool ('Use this for narrative questions') and when not to ('Do not use it to read financial figures: use get_financial_concept'). It also provides a prerequisite: 'Get the accession number from list_filings first,' and notes limitations around older filings and unusual heading formats.

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

Deploy Server