The server provides SEC EDGAR filing data (not web-search guesswork) as MCP tools for Cursor/Claude, focused on ticker symbols, segment revenue, BDC non-accrual, and Form 4 insider filings.
get_trading_symbols — returns every dei:TradingSymbol from the latest 10-K/10-Q plus the legacy entity_info ticker scalar; useful for finding common-stock tickers vs preferred, notes, or dual-class symbols.
get_segment_revenue — returns dimensioned XBRL revenue facts from the latest 10-K/10-Q segmented by product, business, or geographic axes.
get_bdc_nonaccrual — returns BDC non-accrual rate, fair value, named investments, and extraction method for SEC BDCs (814- filers) like ARCC.
get_form4 — returns recent Form 4 insider-filing summaries with transaction lines, open_market flags, and code_counts; distinguishes open-market P/S from grants/exercises/tax withholding (A/M/F).
Tools accept a ticker or CIK and an optional accession; defaults to the latest filing, preferring the original form over amendments like 10-K/A.
The server is designed to prevent hallucinations around segment mix, insider trades, and BDC credit quality, with warnings about parsing gaps and data limitations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@edgar-filings Get the segment revenue breakdown for Apple from its latest 10-K"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Cursor / Claude tools that return SEC filing numbers, not web-search guesses.
Who this is for: people already in an IDE chat who need a ticker’s 10-K/10-Q symbols, segment revenue, BDC non-accrual, or Form 4 lines without writing edgartools glue.
Pain it solves: models invent segment mix, insider trades, and BDC credit quality. These tools return accession, concept, period, open_market, non-accrual method, and the EDGAR index URL so you can check the filing.
What it is not: a research product, a document reader, or a substitute for reading the 10-K. It wraps edgartools for four jobs only. China PE, humanoid robots, and unlisted credit CVs are out of scope — those filings are not on EDGAR.
If uv is already on PATH, paste this into ~/.cursor/mcp.json (Windows: %USERPROFILE%\.cursor\mcp.json). Use a real name and email (SEC FAQ). Same snippet is in examples/cursor.mcp.json and examples/claude.mcp.json.
{
"mcpServers": {
"edgar-filings": {
"command": "uvx",
"args": ["edgar-filings-mcp"],
"env": {
"EDGAR_IDENTITY": "Your Name you@example.com"
}
}
}
}PyPI package edgar-filings-mcp is live. Registry name is io.github.Dxfory/edgar-mcp. Skip Smithery hosted. Pin mcp>=1.9,<2 — MCP 2.x renamed FastMCP; the package already pins that range.
The first uvx launch downloads edgartools (pandas / pyarrow). If the client looks stuck, run uvx edgar-filings-mcp once in a terminal so uv can cache the wheels, then restart the MCP server. After that, initialize is a couple of seconds.
No uv yet:
macOS / Linux:
curl -LsSf https://astral.sh/uv/install.sh | shWindows (PowerShell):
irm https://astral.sh/uv/install.ps1 | iexFrom git instead of PyPI:
uvx --from git+https://github.com/Dxfory/edgar-mcp.git edgar-filings-mcpgit clone https://github.com/Dxfory/edgar-mcp.git
cd edgar-mcp
python -m venv .venvmacOS / Linux:
.venv/bin/python -m pip install -e .Windows:
.\.venv\Scripts\python -m pip install -e .Point the client at that interpreter with args ["-m", "edgar_mcp"].
If PyPI SSL fails (common with a local HTTPS proxy), use a mirror:
python -m pip install -e . -i https://pypi.tuna.tsinghua.edu.cn/simpleRelated MCP server: mcp-edgar
Tool | Returns |
| Every |
| Dimensioned XBRL revenue (product / business / geographic axes) |
| BDC non-accrual rate, fair value, named investments, and extraction method |
| Newest Form 4 summaries, transaction lines, |
form on get_trading_symbols, get_segment_revenue, and get_bdc_nonaccrual is 10-K (default) or 10-Q. get_bdc_nonaccrual only accepts SEC BDCs (814- filers) such as ARCC. There is no fifth tool.
Theme | Agent invents | Tool | Stop |
AI infrastructure | NVIDIA / hyperscaler “AI mix” |
| Do not add a fake AI-capex tool |
Private credit / BDC | Non-accrual, NAV as credit quality, PIK as current |
| Non-accrual ≠ Fitch default rate; PIK can still be accrual |
GP-led continuation vehicles | Deal price and “premium to par” | None | Private secondaries are not EDGAR |
China PE / 具身智能 | Round sizes and factory hours | None | SSE/HKEX, not EDGAR |
entity_info.ticker is last-wins on repeated TradingSymbol facts. Dual-class and preferred tickers can replace the common symbol.
Segment mix is not in get_financials(). Some statement “DETAILED” views drop reportable-segment lines; this server queries dimensioned facts instead.
Form 4 A / M / F are grants, option exercises, and tax withholding — open_market is false.
BDC extraction_method=none or a zero rate plus extractor warnings is a parse gap, not proof the book is clean.
Latest 10-K can be a 10-K/A. The tools prefer the original form so Schedule-of-Investments footnotes are not dropped.
python -m edgar_mcpstdio only. Do not print to stdout.
python tests/run_offline.py
python scripts/smoke_stdio.py
python scripts/pressure.pysmoke_stdio.py only checks initialize + four tool names (no EDGAR). After uvx is on PATH:
python scripts/smoke_stdio.py -- uvx edgar-filings-mcppressure.py hits live EDGAR and needs EDGAR_IDENTITY.
MIT. Filing data is from the SEC EDGAR system; this project is not affiliated with the SEC.
Non-accrual investments from a BDC 10-K or 10-Q, cited to the filing.
Use this instead of guessing private-credit quality. ticker_or_cik must be an SEC BDC (814- filer) such as ARCC. Operating companies like NVDA raise. Non-accrual is the filer's tagged status, not Fitch PCDR and not PIK.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | 10-K | |
| accession | No | ||
| ticker_or_cik | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description is the sole source. It discloses that the tool returns the filer's tagged status, not Fitch PCDR or PIK, and that data is cited to the filing. However, it does not describe the output shape or any error behavior, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but fragmented across five sentences. The sentence 'Operating companies like NVDA raise.' is ambiguous and incomplete. Front-loading the purpose is good, but the structure is not polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations means more burden on the description. It lacks any indication of what fields the result contains, what accession controls, or what happens for an invalid ticker. The description covers key conceptual distinctions but not operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must clarify parameters. It explains ticker_or_cik must be an SEC BDC 814-filer, and implies form accepts 10-K or 10-Q. It gives no meaning for the accession parameter, so compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource: non-accrual investments from SEC BDC 10-K/10-Q filings, with citations. Clearly distinguishes from siblings which are about trading symbols, segment revenue, and form4 filings. The tool's domain is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case: 'Use this instead of guessing private-credit quality.' Also provides an exclusion: 'Operating companies like NVDA raise.' It does not reference sibling tools, but the guidance about what data to use and which companies qualify is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent Form 4 insider filings: who, role, activity, and transaction lines.
limit: 1-20 filings, newest first. P/S are open_market true; A/M/F are false.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker_or_cik | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, and it delivers meaningful behavioral detail: limit range (1-20), ordering (newest first), and the open_market semantics for P/S versus A/M/F transaction codes. This goes well beyond a simple 'get filings' statement. It does not cover response format, errors, or auth, but the disclosed traits are substantive for a read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short lines with every sentence earning its place: the first line states the resource and content, the second defines the limit constraint, the third clarifies transaction-code behavior. It is front-loaded and contains zero filler. The size is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must stand alone. It covers what is returned, the key parameter constraint, and the meaning of the transaction-code values. The only notable gap is a concrete format example for ticker_or_cik, but for a simple two-parameter listing tool the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It does add real semantics for 'limit' (1-20, newest first), but 'ticker_or_cik' is left entirely to inference from its name and the schema. The coverage is partial: one parameter is enriched, the other is not, which is neither a full compensation nor a total failure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (Form 4 insider filings) and enumerates its content (who, role, activity, transaction lines), which is far more informative than a generic verb. This purpose is clearly distinct from the sibling tools, which cover trading symbols, segment revenue, and BDC nonaccrual. No ambiguity remains about what this tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is the right choice for Form 4 insider filing data, and the sibling names are so unrelated that confusion is unlikely. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it. The guidance is adequate but entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dimensioned XBRL revenue facts from a 10-K or 10-Q (product, business, geographic axes).
This is filing data, not a consolidated income statement.
ticker_or_cik: ticker like NVDA or a CIK.
accession: optional filing accession; default is the latest of form.
form: 10-K (default) or 10-Q.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | 10-K | |
| accession | No | ||
| ticker_or_cik | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the data is filing-level XBRL facts, not a summary, and explains parameter defaults. It does not mention rate limits, pagination, or return structure, but the 'not a consolidated income statement' disclaimer is a key behavioral cue. It is adequate for a read-only retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the core purpose, the second clarifies a key distinction, and the following lines succinctly define parameters. No unnecessary words, and the essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the essential purpose, scope, and parameter semantics. It does not describe the exact response format or potential complexity (e.g., multiple facts per filing), but given the simplicity of the parameters and the explicit 'filing data' note, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining every parameter: ticker_or_cik (ticker or CIK), accession (optional, defaults to latest of form), and form (10-K default or 10-Q). This adds significant meaning beyond the bare schema names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Dimensioned XBRL revenue facts from a 10-K or 10-Q', specifying the resource (segment revenue) and the filing context. It also differentiates from a consolidated income statement, making the purpose unambiguous and distinct from sibling tools like get_form4 or get_bdc_nonaccrual.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for segment-level revenue facts) and explicitly warns it is not a consolidated income statement. It also explains default behavior for form and accession. However, it does not explicitly name alternative tools or state when NOT to use it beyond the consolidated statement distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every dei:TradingSymbol fact on a 10-K or 10-Q, plus the legacy entity_info ticker scalar.
Use this when you need the common stock ticker versus preferred, notes, or dual-class symbols.
ticker_or_cik: ticker like NVDA or a CIK.
accession: optional filing accession; default is the latest of form.
form: 10-K (default) or 10-Q.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | 10-K | |
| accession | No | ||
| ticker_or_cik | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does disclose the data scope, default accession behavior, and accepted identifier types (ticker or CIK). However, it omits output structure, error behavior, and whether the result is a list or a scalar structure, which are notable gaps for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short lines with no redundant sentences. It front-loads the purpose, then the usage condition, then parameter semantics. Each sentence earns its place and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the input side well but leaves the return shape under-specified. The agent knows it will get 'every fact' and a scalar, but not whether the return is an array, object, or how symbols are keyed. Given the tool's relative simplicity, this is a moderate gap, so a middle score is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining every parameter: ticker_or_cik with an example ('NVDA' or a CIK), accession as optional with a default of the latest filing of form, and form with allowed values ('10-K' default or '10-Q'). This gives an agent everything needed to fill arguments correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence explicitly states the tool retrieves every dei:TradingSymbol fact from 10-K/10-Q filings plus the legacy entity_info ticker scalar. This is a clear verb+resource with a precise scope, and the use-case line ('common stock ticker versus preferred, notes, or dual-class symbols') distinguishes it from sibling tools covering revenue, nonaccrual, and form4 data. No ambiguity remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger: 'Use this when you need the common stock ticker versus preferred, notes, or dual-class symbols.' This states both the when and the when-not (anything other than common stock ticker). It also clarifies parameter defaults and accepted formats, giving the agent enough to decide to call it without opening schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.2get_bdc_nonaccrualget_segment_revenue1 field changedInput schema / properties / formAdded value: +{
+ "default": "10-K",
+ "title": "Form",
+ "type": "string"
+}get_trading_symbols1 field changedInput schema / properties / formAdded value: +{
+ "default": "10-K",
+ "title": "Form",
+ "type": "string"
+}v0.1.0get_form4get_segment_revenueget_trading_symbolsScored across 4 tools
Each tool targets a distinct data type: trading symbols, segment revenue, BDC non-accrual status, and Form 4 insider filings. There is no overlap in purpose or output, so an agent can reliably select the correct tool.
All four tools follow the consistent 'get_' prefix followed by a descriptive noun phrase (trading_symbols, segment_revenue, bdc_nonaccrual, form4). The naming pattern is predictable and uniform.
Four tools is a modest but reasonable number for a focused EDGAR data extraction server. Each tool addresses a specific analytical need, and the scope does not feel inflated; however, a few more supporting tools could round it out slightly.
The tool set covers a few specialized extractors (symbols, segment revenue, BDC non-accrual, Form 4) but misses obvious core EDGAR operations like retrieving standard financial statements (balance sheet, income statement) or general filing search. The selection feels arbitrary and leaves significant gaps for a server claiming to cover 'edgar-filings'.
Provide AI assistants with real-time access to official SEC EDGAR filings and financial data. Enab…
SEC EDGAR financials, insider trading, and economic data for AI agents. US GAAP + IFRS.
SEC EDGAR filings for AI agents: company lookup, filings, financials, insider trades. No keys.
SEC EDGAR filings for AI agents: company lookup, filings, financials, insider trades. No keys.