EdgarStack

Extract a specific Item section from a filing

get_filing_section

Read-onlyIdempotent

Fetch a 10-K or 10-Q and extract one Item section's text (e.g. itemNumber '1A' for Risk Factors, '7' for MD&A in a 10-K, '2' for MD&A in a 10-Q). Use list_recent_filings first to get the accessionNumber and primaryDocument. If what the user asked for doesn't map cleanly to one Item — e.g. "the financial section" could mean Item 7 (Management's Discussion and Analysis of Financial Condition and Results of Operations, i.e. MD&A — management's narrative) or Item 8 (Financial Statements and Supplementary Data, i.e. the actual audited statements) in a 10-K — ask which they mean, naming both Item numbers AND their official headings, instead of picking one silently; pulling the wrong section wastes the call and can read as if it answered the question when it didn't. The extractor anchors on line-level Item headings and returns a qualityWarning for unusually short sections; it is still heuristic, so check the linked SEC filing when the passage matters.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>",
      "accessionNumber": "<accessionNumber>",
      "primaryDocument": "<primaryDocument>",
      "formType": "<formType>",
      "itemNumber": "<itemNumber>"
    },
    "name": "get_filing_section"
  }
}

Input Schema

Name	Required	Description
`ticker`	Yes
`formType`	Yes
`itemNumber`	Yes	e.g. '1A', '7', '2'
`accessionNumber`	Yes	From list_recent_filings, e.g. 0000320193-24-000123
`primaryDocument`	Yes	From list_recent_filings, e.g. aapl-20240928.htm

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered; the description adds substantive behavior beyond them — line-level heading anchoring, a qualityWarning for unusually short sections, and the admission that extraction is heuristic and should be verified against the linked SEC filing when the passage matters.

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?

Front-loaded with the action and an example, then prerequisites, then ambiguity handling, then caveats — a logical ordering with no filler sentences. The Item 7 / Item 8 parenthetical expansion is long, though it is doing real disambiguation work rather than padding.

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 five required params, no output schema, and a heuristic extractor, the description covers the prerequisite chain, the ambiguity decision rule, the failure signal (qualityWarning), and the verification path. Nothing an agent needs in order to call this correctly or interpret the result is missing.

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 60%, and the description compensates meaningfully by mapping itemNumber values to real section identities per form type (1A/7/2) and reiterating the source of accessionNumber and primaryDocument. ticker and formType receive no added explanation, so it stops short of full coverage.

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 ('Fetch a 10-K or 10-Q and extract one Item section's text') and immediately grounds it with concrete examples ('1A' for Risk Factors, '7' for MD&A in a 10-K, '2' in a 10-Q). An agent can distinguish this from siblings like full_text_search or get_financials without opening any schema.

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?

Gives an explicit prerequisite call ('Use list_recent_filings first to get the accessionNumber and primaryDocument') and detailed when-not guidance: if a request doesn't map cleanly to one Item, ask the user, naming both Item numbers and official headings rather than silently picking one. It even explains the cost of the wrong choice (wasted call, false-looking answer).

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

All EdgarStack tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?