market-research-mcp

get_filing_section

Retrieve a specific section of a 10-K or 10-Q SEC filing as plain text in chunks, with cursor-based pagination for long sections.

Instructions

Plain text of one section of a 10-K or 10-Q filing, in chunks of about 24,000 characters. section: an item such as "1A", "Item 7", "7A", "1", "2", "Part II Item 1A", or a name such as "Risk Factors" or "MD&A" (10-Q: MD&A is Part I Item 2). Pass the returned next_cursor to get the next chunk. Get accession numbers from list_filings. Source: SEC EDGAR.

Input Schema

Name	Required	Description	Default
`cursor`	No
`ticker`	Yes
`section`	Yes
`accession`	Yes

Output Schema

Name	Required	Description	Default
`cik`	Yes
`form`	Yes
`text`	Yes
`as_of`	Yes
`notes`	No
`stale`	No
`source`	Yes
`ticker`	Yes
`exhibit`	No
`section`	No
`accession`	Yes
`source_url`	Yes
`chunk_index`	Yes
`next_cursor`	No
`total_chars`	Yes
`retrieved_at`	Yes
`total_chunks`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 24, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the burden and usefully discloses chunk size (~24,000 characters), cursor-based pagination, plain-text output, and SEC EDGAR as the source. It does not mention rate limits, authentication, or error behavior, but the core retrieval behavior is clear.

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 front-loaded with the core operation and then efficiently covers section formats, pagination, and accession sourcing. Every sentence adds useful information without wasting space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be fully described, and the description still explains chunking and cursor behavior. It is nearly complete for invocation, though ticker semantics and any error/rate-limit context are absent.

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 0%, so the description must explain parameters, and it does so well for section, cursor, and accession. Ticker is left implicit as a company ticker, which is a minor gap.

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 verb and resource: retrieving the plain text of one 10-K or 10-Q section, returned in chunks. It does not explicitly distinguish this from sibling tools such as get_filing_exhibit, but the section-level scope is clear.

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 clear operational context: get accession numbers from list_filings, use section identifiers such as "1A" or "Risk Factors," and pass next_cursor for subsequent chunks. It does not explicitly say when to choose this over get_filing_exhibit or when not to use it.

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

Deploy Server