What can you do with this server?

This server provides read-only access to SEC EDGAR public filings and company data, enabling research into companies, securities offerings, and financial disclosures. * Resolve Issuers: Find a company's CIK, legal name, tickers, and exchange by name or ticker. * List Filings: Retrieve the most recent SEC filings for a company, optionally filtered by form type (e.g., 10-K, 8-K, C, D). * Search Filings: Full-text search across all filing documents with optional date range and form type filters. * Get Filing Details: Open a specific filing to view its metadata, form type, filing date, and associated documents. * Parse Offerings: Extract detailed information from Form C (Reg CF), Form D (Reg D), and Form A (Reg A) — including offering amounts, investors, industry, financials, and key personnel. * Get Recent Offerings: Retrieve recent Reg CF, Reg D, or Reg A securities offerings, with optional state filtering. * Company Financials: Get headline annual financials (revenue, net income, assets, liabilities) from XBRL data. * Insider Data: List a company's officers, directors, and major owners, plus recent insider trading transactions (Form 4) with owner, role, shares, and price details. * Filing Document Text: Fetch paginated clean text from a filing document for reading or summarization.

How do I use edgar-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@edgar-mcp Show me recent 10-K filings for Microsoft" 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.

edgar-mcp

by mcpwright

Overview Schema Related Servers Score Discussions

Python

Remote

edgar-mcp

SEC EDGAR filings, inside your agent. An MCP server that lets an LLM resolve companies, search filings, and pull recent securities offerings straight from the SEC — built on Anthropic's official mcp Python SDK.

All tools are read-only and hit public SEC endpoints (no API key required).

Status: 11 tools, working today (see below). Published on PyPI as mcpwright-edgar and in the official MCP Registry. See the roadmap for what's next.

Tools

Tool	What it does
`lookup_issuer(query, limit=10)`	Resolve a ticker or company name → CIK, legal name, tickers, exchange. Works for exchange-listed and private / non-exchange filers (Reg CF / Reg A issuers, funds).
`list_filings(cik_or_query, form_type=None, limit=20)`	An issuer's most recent filings, newest first. Optional form-type filter (e.g. `10-K`, `C`, `D`).
`search_filings(query, forms=None, date_from=None, date_to=None, limit=20)`	Full-text search across filing documents.
`get_recent_offerings(form="C", since=None, state=None, limit=20)`	Recent securities offerings, newest first — `form="C"` (Reg CF), `"D"` (Reg D), or `"A"` (Reg A — 1-A offering statements plus 253G2 offering circulars, where the per-share price and any "price walk-up" live), optionally filtered by issuer `state` (e.g. `"CA"`).
`get_filing(accession_or_url, cik=None)`	Open one filing: form, filing date, primary-document link, and every document in the filing.
`get_form_d_details(accession_or_url, cik=None)`	Parse a Form D (Reg D) raise: offering amount, sold/remaining, min investment, # investors, industry, revenue range, security types, exemptions, and the officers/directors/promoters.
`get_form_c_details(accession_or_url, cik=None)`	Parse a Form C (Reg CF) raise: target/max amount, price, security type, deadline, intermediary, employees, and a two-year financial snapshot (revenue, net income, assets, debt).
`get_company_facts(cik_or_query)`	Headline financials from a public company's XBRL facts: latest annual revenue, gross/operating income, net income, assets, liabilities, equity, cash.
`get_filing_text(url, offset=0, max_chars=20000)`	Fetch a document's text (HTML stripped) for reading/summarizing — paginated, since filings can exceed 1M characters.
`get_insiders(cik_or_query, limit=25)`	A company's insiders (officers, directors, >10% owners) from recent Section 16 filings, with roles.
`get_insider_trades(cik_or_query, limit=20)`	Recent insider transactions (Form 4): owner, role, buy/sell/grant, shares, price, shares owned after.

Related MCP server: sec-edgar-mcp

Install

Requires Python 3.12+. The zero-clone way to run it (the PyPI package is mcpwright-edgar; the command, server, and tools are all "edgar"):

uvx mcpwright-edgar

Claude Code

claude mcp add edgar -- uvx mcpwright-edgar

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "edgar": { "command": "uvx", "args": ["mcpwright-edgar"] }
  }
}

OpenAI Agents SDK (Python)

It's a standard MCP server, so it works with any MCP-capable client — not just Claude. With the OpenAI Agents SDK:

from agents import Agent, Runner
from agents.mcp import MCPServerStdio

async def main():
    async with MCPServerStdio(
        name="edgar",
        params={
            "command": "uvx",
            "args": ["mcpwright-edgar"],
            "env": {"EDGAR_MCP_USER_AGENT": "your-app you@example.com"},
        },
    ) as edgar:
        agent = Agent(
            name="Analyst",
            instructions="Use the EDGAR tools for SEC filings and company data.",
            mcp_servers=[edgar],
        )
        result = await Runner.run(
            agent, "Recent Reg D raises in California — who's behind the biggest?"
        )
        print(result.final_output)

Any other MCP client (Cursor, VS Code, Cline, Goose, Zed, …)

They all launch a stdio MCP server the same way — point yours at:

{
  "mcpServers": {
    "edgar": {
      "command": "uvx",
      "args": ["mcpwright-edgar"],
      "env": { "EDGAR_MCP_USER_AGENT": "your-app you@example.com" }
    }
  }
}

Hosted chat connectors (e.g. ChatGPT connectors) expect a remote MCP server over Streamable HTTP; mcpwright-edgar runs locally over stdio. Running it behind Streamable HTTP for a hosted endpoint is straightforward if you need that.

SEC etiquette: the SEC requires a descriptive User-Agent with contact info and rate-limits to ~10 req/s. Set your own via the EDGAR_MCP_USER_AGENT env var (e.g. "your-app your-email@example.com"). The client throttles and retries for you.

Caching: responses are cached in-memory (byte-budgeted LRU) to cut latency and SEC load — immutable filing-archive content for days, the ticker map for 24h, everything else briefly. Set EDGAR_MCP_CACHE=0 to disable.

Develop

git clone https://github.com/mcpwright/edgar-mcp && cd edgar-mcp
uv sync
uv run pytest                       # tests (mocked SEC responses)
uv run ruff check . && uv run ruff format --check .   # lint + format
uv run mypy src tests               # strict type checking
uv run mcp dev src/edgar_mcp/server.py   # poke the tools in the MCP Inspector

Roadmap

get_recent_offerings(form=C|D) — recent Reg CF / Reg D raises
get_filing(accession_or_url) — open a filing and list its documents
get_form_d_details(...) — parse Reg D offering data (amount, investors, people)
get_form_c_details(...) — parse Reg CF offering data (target/max, financials, terms)
get_insiders / get_insider_trades — Section 16 (Form 3/4/5) insiders & trades
State filter on get_recent_offerings (industry isn't filterable — EDGAR omits SIC on these listings; screen via get_form_d_details.industry_group)
Reg A support in get_recent_offerings (Form 1-A statements + 253G2 offering circulars)
get_company_facts(cik) — XBRL headline financials
get_filing_text — return a document's text for summarization
Published to PyPI (mcpwright-edgar) + the official MCP Registry (io.github.mcpwright/edgar-mcp)
get_form_a_details — parse Reg A (Form 1-A) offering data
Older-filing metadata (beyond the recent-submissions window)

Privacy

edgar-mcp runs entirely on your machine and collects, stores, or transmits no personal data — no accounts, no tracking, no telemetry. Its only outbound requests go to the U.S. SEC's EDGAR services (data.sec.gov, efts.sec.gov, www.sec.gov) to fetch the public filings you ask for; no API key is needed. One honest note: the SEC's fair-access policy asks for a descriptive User-Agent with contact info (EDGAR_MCP_USER_AGENT="your-app you@example.com") — whatever you set there is sent to the SEC with each request, and nowhere else. Responses are cached in memory only; nothing is persisted to disk.

Full policy: https://mcpwright.com/privacy/

Questions & feedback

Questions, ideas, or "could it do X?" → Discussions
Bugs & concrete feature requests → Issues

Contributions welcome — and if you build something with it, I'd love to hear about it.

Part of mcpwright · built by Devender Gollapally

Available Tools

3 tools

list_filingsA

Read-only

List the most recent filings for one issuer, newest first.

`cik_or_query`: a CIK (digits) or a ticker/name to resolve.
`form_type`: optional prefix filter, e.g. "10-K", "8-K", "C", "D".

ParametersJSON Schema

Name	Required	Description	Default
`cik_or_query`	Yes
`form_type`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations indicate readOnlyHint and openWorldHint, so description reinforces that this is a read operation. It discloses ordering and the resolution behavior for cik_or_query. However, it does not mention any rate limits, pagination, or the effect of the 'limit' parameter, which would add transparency.

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 extremely concise, with two lines of text plus parameter explanations. It is front-loaded with the main purpose and includes only essential details. Every sentence adds value.

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?

Given the tool's complexity (3 parameters, output schema exists), the description covers the main functionality and key parameters. It could improve by explaining the 'limit' parameter, but overall it is sufficient for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. It adds meaning for 'cik_or_query' (accepts digits or ticker/name) and 'form_type' (prefix filter). However, 'limit' parameter is entirely undocumented in description, leaving its purpose unclear.

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 clearly states the action ('list'), resource ('filings'), scope ('for one issuer'), and ordering ('newest first'). It distinguishes from sibling tools like 'search_filings' which likely provides more extensive search, and 'lookup_issuer' which likely finds issuer info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but does not explicitly state when to use it versus alternatives. It mentions parameter usage (CIK/ticker resolution and form type filter) but lacks guidance on when not to use this tool or when to prefer 'search_filings'.

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

lookup_issuerA

Read-only

Resolve a company name or ticker to its SEC CIK and basic identity.

`query`: a ticker (e.g. "AAPL") or part of a company name (e.g. "Apple").
Returns matching issuers with their 10-digit CIK, legal name, tickers, and
exchange. Resolve a CIK here first — the other tools key off it.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

The description adds value beyond annotations by explaining the return values (CIK, legal name, tickers, exchange) and the tool's role as a prerequisite for other tools. Annotations already declare readOnlyHint and openWorldHint, which are consistent with 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.

Conciseness5/5

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

The description is succinct with three sentences, front-loading the purpose. Every sentence adds value, with no redundant or extraneous information.

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?

Given the tool's simplicity, existence of output schema, and annotations, the description is complete. It explains the query usage, output, and workflow integration. The limit parameter is not detailed, but it's a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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. It explains the query parameter (ticker or name part) but does not describe the limit parameter. This provides partial coverage for a simple tool, warranting a score of 3.

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 clearly states the tool resolves a company name or ticker to its SEC CIK and basic identity, using specific verbs and resources. It distinguishes from siblings list_filings and search_filings which operate on filings, not issuers.

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?

The description provides clear context: use this tool to obtain a CIK before using other tools. It gives examples of input (ticker or name part) and explains the output. It doesn't explicitly state when not to use it, but the purpose is well-defined and distinct from siblings.

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

search_filingsA

Read-only

Full-text search across SEC filing documents.

`query`: free text (use quotes inside the string for exact phrases).
`forms`: optional list of form types to restrict to, e.g. ["10-K", "8-K"].
`date_from` / `date_to`: ISO dates (YYYY-MM-DD).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`forms`	No
`date_from`	No
`date_to`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint: true and openWorldHint: true, so the description is not responsible for those. The description adds context about full-text search and parameter formatting (e.g., 'use quotes for exact phrases'), but does not disclose details like pagination, result limits beyond the limit parameter, or potential idiosyncrasies of SEC filings. With annotations covering safety, this is adequate but not richly transparent.

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 brief and front-loaded with the purpose. It uses newlines for readability and each sentence adds value. No redundant information.

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?

Given 5 parameters, an output schema exists, and annotations are provided, the description covers most necessary context. It explains the search functionality and the main parameters but omits the 'limit' parameter. For a simple search tool with output schema, this is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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. It adds meaning for query (free text, quotes for exact phrases), forms (optional list of form types), and date_from/date_to (ISO dates). However, it does not describe the 'limit' parameter, which has a default of 20. This is a partial but useful addition beyond the schema.

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 clearly states 'Full-text search across SEC filing documents,' specifying the verb (search), resource (SEC filing documents), and scope (full-text). This distinguishes it from siblings like list_filings (likely list without full-text) and lookup_issuer (lookup issuer data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides parameter details but no explicit guidance on when to use this tool versus alternatives. It implies usage through the context of SEC filings but does not state exclusions or recommend alternatives. For example, it doesn't clarify when to use search_filings vs list_filings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0May 30, 2026
- First observedlist_filings
- First observedlookup_issuer
- First observedsearch_filings

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: lookup_issuer resolves entities, list_filings retrieves recent filings for a specific issuer, and search_filings performs full-text search across documents. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: lookup_issuer, list_filings, search_filings. The verbs are distinct and descriptive, and the pattern is uniform across the set.

Tool Count4/5

With 3 tools, the set is slightly minimal but covers the core operations for SEC filing access: entity resolution, listing filings, and full-text search. The count is reasonable for a focused domain, though it feels a bit thin for comprehensive coverage.

Completeness3/5

The tool set covers entity lookup, recent filing listing, and full-text search, which are essential, but lacks a tool to retrieve the actual filing content or metadata for a specific filing. This is a notable gap for agents that may need to fetch filing details after discovery.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

sec A
io.github.pipeworx-io
SEC MCP — SEC EDGAR public APIs (free, no auth)
Government Data Finance Open Data
342
Edgar A
io.github.pipeworx-io
EDGAR MCP — SEC EDGAR public APIs (free, no auth)
Government Data Finance Open Data
462
secapiOAuth
ai.secapi
SEC & financial-data MCP: filings, financials, ownership, factors, fund letters, prompts.
Finance Search Government Data
2
secedgar-mcp-server A
io.github.cyanheads
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
Finance Government Data Open Data
1629

Related MCP Servers

SEC EDGAR MCP
Finance Government Data
stefanoamorelli
A
license
C
quality
B
maintenance
MCP server for accessing SEC EDGAR filings. Connects AI assistants to company filings, financial statements, and insider trading data with exact numeric precision.
Updated 16 days ago (2026-08-21 10:17 UTC)
21
355
AGPL 3.0
sec-edgar-mcp
Finance Government Data Open Data
guptaprakhariitr
A
license
Not graded
quality
D
maintenance
Hosted MCP server that gives AI agents real-time access to SEC EDGAR filings search, 10-K/8-K reading, XBRL financial facts, and insider-trade (Form 4) alerts.
Updated 3 months ago (2026-06-11 08:39 UTC)
25
1
MIT
edgar-mcp
Finance Government Data
asp53826
A
license
A
quality
A
maintenance
An MCP server that enables models to access SEC EDGAR filings, filing text, and XBRL financial facts with caching, rate limiting, and iXBRL stripping.
Updated 7 days ago (2026-08-30 09:09 UTC)
8
MIT
sec-intelligence-mcp
RAG Systems Vector Databases Finance
jahanv01
A
license
A
quality
B
maintenance
MCP server for SEC EDGAR filing intelligence, providing tools for fetching, chunking/embedding, retrieval, and evaluation of filings.
Updated 4 days ago (2026-09-02 18:24 UTC)
1
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mcpwright/edgar-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server