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-mcp What does Apple's latest 10-K say about risk factors?"
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.
An MCP server for SEC EDGAR, built so a model can read one section of a 10-K instead of all of it.
No API key. No account. SEC filings are public record and the data is free.
"What does Apple say about supply chain risk?"
read_filing_section(company="AAPL", accession="0000320193-25-000079",
section="risk_factors")
-> Item 1A — Risk Factors
17,040 tokens, from a 54,955-token documentEDGAR is not hard to call. It is hard to call well.
A 10-K runs 300 pages. Handed to a model whole, it costs 50,000+ tokens and crowds out the reasoning the answer needs. Most EDGAR wrappers mirror the API, return whole documents, and leave the hard parts — which section, how much of it, which XBRL tag — to the model.
Those hard parts are the product. This server is six tools, and the design decisions behind them are the point:
Six tools, not thirty. A model needs to find a company, see what it filed, read part of one filing, and look up a number. Every extra tool is context spent before the first useful call.
Accept what a model actually has. Every tool takes company as plain text —
"Apple", "AAPL", or a CIK — and resolves it internally. Forcing a lookup call
before every real call wastes a turn on a problem the server can solve.
Never return a whole filing. read_filing_section returns one item, capped at
max_tokens, with an offset to continue and an explicit note about what was cut.
Silent truncation teaches a model to trust a partial answer.
Errors are instructions. Every failure says what to call next:
'bank' matched several registrants and none clearly. Call this tool again with
a ticker or the full legal name. Candidates: Bank OZK (OZK, CIK 0001569650);
Bank7 Corp. (BSVN, CIK 0001746129); BANK BRADESCO (BBD, CIK 0001160330)...Related MCP server: edgar-mcp
Every 10-K names each item at least twice: once in the table of contents, once at the actual section. Match naively and you return forty words of navigation that look exactly like a successful extraction.
The rule used here: take the occurrence with the most text before the next item heading. A contents entry is followed immediately by the next entry; the real section is followed by the section. Length separates them, and it holds across filers who agree on nothing else about formatting.
Apple reports RevenueFromContractWithCustomerExcludingAssessedTax. Older filers
use Revenues. Some use SalesRevenueNet. A server that knows one tag returns
"no data" for most of the market.
Worse: filers switch tags mid-life. NVIDIA's older years sit under one revenue tag and its recent years under another. Stopping at the first tag that returns anything silently serves four-year-old numbers that look perfectly current.
So every friendly concept maps to a list of candidate tags, all are fetched, the newest-reporting one leads, and the others fill in periods it lacks. The response names the tag that answered, because in finance the definition matters as much as the number.
pip install -e .
export EDGAR_MCP_USER_AGENT="Your Name you@example.com"The SEC requires a User-Agent with real contact details and blocks requests without one. The server refuses to start a request rather than let you get rate-limited mysteriously.
Claude Code:
claude mcp add edgar -e EDGAR_MCP_USER_AGENT="Your Name you@example.com" -- edgar-mcpClaude Desktop — in claude_desktop_config.json:
{
"mcpServers": {
"edgar": {
"command": "edgar-mcp",
"env": { "EDGAR_MCP_USER_AGENT": "Your Name you@example.com" }
}
}
}Tool | What it does |
| Name or ticker to CIK, ranked with a confidence score. Refuses rather than guess. |
| What a company filed, newest first, filterable by form and date. |
| Which items a filing contains and what each costs to read, in tokens. |
| The main tool. One section, budgeted, with an offset to continue. |
| A reported figure across periods, from XBRL. 14 concepts. |
| Full-text search across all filings, 2001 to present. |
Most MCP servers ship with no evidence they work. These produce a number, run against live SEC data, and gate on a floor.
python3 evals/run_eval.py company resolution
accuracy_on_answerable 100.0% (35/35)
refusal_rate_on_ambiguous 100.0% (5/5)
section retrieval
grounded 100.0%
recall_at_1 38.5%
recall_at_3 100.0%
cases 13The refusal rate matters as much as the accuracy. A confident wrong CIK sends every later call to the wrong company and never looks wrong. Five golden cases are queries that should be refused, and refusing them is scored as success.
recall_at_1 of 38.5% is reported honestly rather than hidden. The retrieval
eval ranks sections by naive term overlap, and financial language repeats across
sections — "competition" appears in Business and in Risk Factors. grounded at
100% is the number that matters here: the section that should answer a question
does contain the answer. Ranking is a scoring-function problem, not an extraction
problem, and pretending otherwise would be the easy lie.
The resolution eval failed on Exxon Mobil, and the cause was not the matcher.
ExxonMobil reorganized: a holding company (CIK 2115436) now carries the XOM
ticker while the operating company (CIK 34088) still files the 10-K. Both are
defensible answers to the bare name. The eval now accepts either, and
list_filings tells the caller which forms each entity actually has.
That class of split exists across the market and I did not know about it before writing the eval. That is the argument for writing evals.
python3 tests/test_protocol.pyNine checks over the real MCP stdio protocol, not direct function calls — launching the server as a subprocess and talking to it the way a client does. Direct calls skip serialization, schema validation, and error translation, which are the three places an MCP server actually breaks.
One of those checks exists because of a bug found this way: the SDK treats an
unrecognized exception as a crash and replaces the message with
Error executing tool <name>. Every recovery instruction written into the error
text was being thrown away. The fix is to raise ToolError, whose message is
delivered intact — invisible from a direct call, obvious over the protocol.
Full-text search starts at 2001. Older filings are listed but not searchable.
XBRL means US-GAAP. Foreign private issuers filing under IFRS often return no facts. The error says so instead of returning an empty list.
Part III is frequently incorporated by reference to the proxy, so Items
10–14 are often one sentence pointing at a DEF 14A. list_filing_sections
shows the real size so this is visible before you read.
Section extraction is heuristic. It handles the common 10-K layouts. Exotic formatting, and some older scanned filings, will not parse cleanly.
Responses are cached to ~/.cache/edgar-mcp for 24 hours. Set
EDGAR_MCP_CACHE to move it.
This reads public filings. It does not interpret them, and nothing it returns is a recommendation.
MIT
Resolve a company name or stock ticker to its SEC CIK number, which every other tool needs. Use this when a name is ambiguous or you want to confirm which entity you are about to read. Only companies that file with the SEC are here: no private companies, and most foreign issuers only if they file a 20-F. Returns ranked candidates with a confidence score.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return behavior ('Returns ranked candidates with a confidence score') and scope constraints (SEC filers only). It could add failure behavior for no-match queries, but the disclosed behavior is substantive and non-contradictory.
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?
Four sentences with purpose front-loaded, followed by usage, scope, and return behavior. Each sentence earns its place, though it could trim minor redundancy in the scope sentence.
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?
Output schema exists and covers the return values, so the description need not restate them. It covers purpose, usage, scope, and return behavior. The main gap is the undocumented limit parameter and missing no-match failure handling.
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 for both parameters. It implies the query accepts a name or ticker, but it never explicitly documents the query or the limit parameter at all. The limit's effect on candidate ranking is entirely undocumented.
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 states a specific verb and resource ('Resolve a company name or stock ticker to its SEC CIK number') and clarifies its role as the prerequisite every other tool needs. This clearly distinguishes it from the sibling filing/reading tools, which operate on a CIK after it is obtained.
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 explicit when-to-use conditions ('Use this when a name is ambiguous or you want to confirm which entity you are about to read') and clear exclusions (no private companies, foreign issuers only if they file a 20-F). The scope boundaries are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a reported financial figure across recent periods, from structured XBRL data. Use this for any number — it is far more reliable than reading figures out of filing prose.
Concepts: revenue, net_income, operating_income, gross_profit, total_assets, total_liabilities, stockholders_equity, cash, eps_basic, eps_diluted, rnd_expense, shares_outstanding, long_term_debt, operating_cash_flow.
Each maps to one or more US-GAAP tags and the response names the tag that answered, because the exact definition matters. Annual figures by default; set annual=false for every period as reported, including quarters.
| Name | Required | Description | Default |
|---|---|---|---|
| annual | No | ||
| company | Yes | ||
| concept | Yes | ||
| periods | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that lookups come from structured XBRL, that concepts map to one or more US-GAAP tags, and that the response names the answering tag because exact definition matters. It does not mention rate limits, authentication, or failure behavior, but those are secondary for a read-only lookup.
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 longer than minimal but front-loaded with the core purpose and every subsequent sentence adds value: the concept vocabulary, the tag explanation, and the annual/quarterly switch. The concept list is the only bulk, and it is directly useful for choosing the 'concept' parameter.
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 4-parameter read-only tool with an output schema, the description covers the main parameters and behavioral context well. The main gap is the unstated meaning of 'periods' and company identifier format, but defaults and the concept list make the tool callable without guessing.
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%, yet the description partially compensates by listing the valid 'concept' values and explaining 'annual' vs 'annual=false'. However, it does not explain the 'periods' parameter (beyond 'recent periods') or how 'company' is identified, so the 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?
The description opens with a specific action and object: 'Look up a reported financial figure across recent periods, from structured XBRL data.' It clearly positions this as the tool for extracting numeric facts and distinguishes it from the sibling filing/search tools, whose scope is prose and document navigation.
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?
'Use this for any number — it is far more reliable than reading figures out of filing prose' is an explicit when-to-use directive with a warning against the alternative. It also gives parameter-level guidance: annual by default, 'set annual=false for every period as reported, including quarters.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List what a company has filed with the SEC, newest first. Filter by form type: 10-K is the annual report, 10-Q quarterly, 8-K a material event, DEF 14A the proxy statement (executive pay and board), S-1 an IPO registration, 20-F a foreign issuer's annual report, 4 an insider trade. The form filter matches on prefix, so '10-K' also returns 10-K/A amendments. Returns accession numbers, which read_filing_section needs.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | ||
| limit | No | ||
| since | No | ||
| company | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses ordering (newest first), filtering, and the prefix-matching behavior for form types. It also states the return content (accession numbers). However, it does not mention whether the operation is read-only (likely safe but unstated), whether authentication is needed, or any pagination/limits beyond the default limit parameter. It gives some behavioral context but not comprehensive coverage.
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 well-structured: a front-loaded purpose sentence, a list of form-type definitions, the prefix behavior, and a closing note about the return value's use. It is longer than minimal but each sentence adds value—especially the form-type glossary, which is genuinely helpful for an agent. No wasted words.
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?
The description covers the essential output (accession numbers) and the form filter, but it omits details on the 'since' parameter (date format?), 'limit' semantics, and whether the 'company' parameter expects a ticker, CIK, or name. It also does not reference find_company as a prerequisite for obtaining a company identifier, which is a likely need. The tool is moderately complex (4 params, no annotations), so more explanation is warranted.
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 must compensate. It thoroughly explains the 'form' parameter, including what each common form type means and the prefix-matching rule. It implicitly covers 'company' (a company identifier) and mentions 'limit' indirectly via the default in schema, but it does not explain 'since' (likely a date filter) or how 'limit' behaves (e.g., maximum, pagination). Partial compensation only.
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 opens with a clear verb+resource statement: 'List what a company has filed with the SEC, newest first.' It specifies the resource (SEC filings), the ordering (newest first), and distinguishes itself from read_filing_section by mentioning accession numbers as its output. It also enumerates form types with plain-language meanings, giving an agent enough to decide if this is the right tool without opening the schema.
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 usage: it is the tool to list filings before calling read_filing_section, and it explains form filters. However, it never explicitly says when not to use it or contrasts it with search_filings (which likely handles keyword search). It gives a hint that this is for getting accession numbers, but lacks an explicit 'use search_filings for full-text' or 'use find_company first' note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show which numbered items a filing actually contains, and how many tokens each one would cost to read. Call this before read_filing_section when you are not sure a section exists or want to budget the read. Many companies incorporate Part III by reference to their proxy, so Items 10-14 are often a single sentence pointing elsewhere.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | ||
| accession | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full transparency burden. It discloses real behavioral traits: it lists only sections actually present, reports token costs, and warns that Items 10-14 are often a single by-reference sentence. It stops short of stating read-only guarantees or error behavior, but 'Show' and 'read' make the read-only nature strongly implicit.
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?
Three sentences, each earning its place: the first defines the tool's core output, the second gives usage guidance, and the third adds a valuable domain caveat. It is front-loaded and contains no filler.
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?
Given that an output schema exists, not explaining return values is acceptable. The description supplies enough context for a straightforward list-type tool: what it returns at a high level, when to call it, and a relevant edge-case pattern. The main missing piece is guidance on how to obtain or format the accession parameter, but overall it is nearly 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%, and the description does not explain the format or provenance of the two required parameters. 'company' and 'accession' are somewhat self-explanatory, but the description never clarifies whether company is a name, ticker, or CIK, nor that accession likely comes from a prior list_filings call. The description must compensate for the missing schema documentation and does not.
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 states a specific verb ('Show') and resource ('which numbered items a filing actually contains'), and adds a distinct purpose beyond its name: token-cost budgeting. It is clearly differentiated from sibling read_filing_section by framing this as the listing/budgeting step, not the content-reading step.
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 explicitly says when to call this tool: 'Call this before read_filing_section when you are not sure a section exists or want to budget the read.' This directly names the alternative and the conditions that select this tool, leaving no ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read ONE section of a filing rather than the whole document. This is the main tool: a 10-K is typically 50,000+ tokens and you almost never need all of it.
Sections: business (Item 1, what the company does), risk_factors (1A, what management says could go wrong — the most quoted section), properties (2), legal_proceedings (3), market_for_stock (5), mdna (7, management's own explanation of the results — read this before the financial statements), market_risk (7A), financial_statements (8), controls (9A), directors (10), executive_comp (11).
Output is capped at max_tokens. If the section is longer you get an offset to continue from; the response always says how much was cut.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| company | Yes | ||
| section | Yes | ||
| accession | Yes | ||
| max_tokens | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses output truncation behavior ('Output is capped at max_tokens'), the offset continuation mechanism, and that the response indicates how much was cut. It does not mention authentication, rate limits, or error behavior, but for a read tool the disclosed behaviors are substantial and directly relevant to invocation.
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 compact and front-loaded: the first sentence states the core purpose and the key contrast with whole-document reads. The section list is a scannable parenthetical enumeration, and the output behavior is summarized in two short sentences. Every sentence earns its place; no filler.
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?
Given the tool's moderate complexity (5 params, no annotations, no enums in schema), the description covers the most critical context: section semantics, output truncation, and continuation. It does not explain how to obtain 'accession' or 'company' values, but those are likely covered by sibling tools (list_filings, find_company). The presence of an output schema also reduces the need to describe return values. A small gap remains around error cases or what happens with invalid section names, but overall the description is complete enough for an agent to call the tool correctly.
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 explains the meaning of 'section' by listing valid values, and it explains 'offset' and 'max_tokens' behaviorally ('If the section is longer you get an offset to continue from'; 'Output is capped at max_tokens'). It does not explain 'company' or 'accession' formats, but those are likely established by sibling tools (find_company, list_filings), so the compensation is strong where it matters most.
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 states a specific verb ('Read') and resource ('ONE section of a filing'), and explicitly contrasts with reading the whole document. It also enumerates the exact section identifiers (business, risk_factors, etc.), which makes the tool's scope unambiguous and distinguishes it from sibling tools like list_filing_sections and get_financial_facts.
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 explicit guidance on when to use this tool: it is 'the main tool' for reading filing sections, and it advises reading mdna before financial statements. It also implies when not to use it (when you need the whole document) and provides a curated list of sections, which helps an agent select the right section without opening the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the full text of all EDGAR filings from 2001 onward. Use this to find WHO discusses something — 'which companies mention quantum computing risk' — rather than to read a company you have already identified.
A multi-word query is matched as an exact phrase. Results are filings, not passages, so follow up with read_filing_section to read one. Narrow with forms (e.g. '10-K') and a date range when a query is common.
| Name | Required | Description | Default |
|---|---|---|---|
| forms | No | ||
| limit | No | ||
| query | Yes | ||
| date_to | No | ||
| date_from | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it discloses non-obvious behavior: coverage starts in 2001, multi-word queries are exact phrases, and results are filings rather than passages. It does not mention pagination, rate limits, or authorization, but for a search tool the disclosed semantics are the critical part.
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 front-loaded with the core purpose, and each sentence adds value: use case, matching semantics, result granularity, follow-up, and narrowing strategy. There is no filler.
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 full-text search tool with an output schema, it covers the key invocation concerns: what is searched, how queries match, what results contain, and how to proceed. Minor omissions such as limit semantics and exact date formats are the only gaps.
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 adds meaning for query (exact-phrase matching) and mentions forms/date range with an example, but it does not explain the limit parameter or date format details.
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 verb and resource: 'Search the full text of all EDGAR filings from 2001 onward.' It also differentiates the tool from reading a specific company's filing by framing it as 'find WHO discusses something,' which separates it from the sibling filing-reading tools.
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?
Explicitly says when to use it ('find WHO discusses something') and when not ('rather than to read a company you have already identified'). It names the follow-up alternative (read_filing_section) and gives concrete narrowing guidance for common queries via forms and date range.
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.
v0.1.0find_companyget_financial_factslist_filing_sectionslist_filingsread_filing_sectionsearch_filingsScored across 6 tools
Each tool serves a clearly distinct purpose: company resolution (find_company), filing listing (list_filings), section listing (list_filing_sections), section reading (read_filing_section), structured financial data (get_financial_facts), and full-text search (search_filings). There is no overlap; even list_filings and search_filings address different discovery needs (known company vs. unknown company).
All tool names follow a consistent verb_noun snake_case pattern (find_company, list_filings, list_filing_sections, read_filing_section, get_financial_facts, search_filings). The pattern is uniform and clearly reflects the action each tool performs.
Six tools is well-scoped for an EDGAR MCP server. Each tool covers a distinct part of the workflow (entity resolution, filing discovery, structure inspection, content reading, structured data extraction, and cross-company search) without redundancy or unnecessary bulk.
The tool surface covers the core EDGAR workflows end-to-end: finding a company, listing its filings, inspecting filing structure, reading specific sections, extracting structured financial facts, and searching across all filings. There are no obvious dead ends; the chain from find_company → list_filings → list_filing_sections → read_filing_section is complete, and get_financial_facts provides a reliable alternative for numerical data.
Access SEC filings efficiently (10-K, 10-Q, etc), save time and tokens, and get cited answers.
Agent-native SEC filing data: statements assembled, filings read and synthesized. No API key.
Certified SEC EDGAR fact memory for AI agents with zero hallucination and filing provenance.
SEC EDGAR filings for AI agents: company lookup, filings, financials, insider trades. No keys.
