What can you do with this server?

This server provides AI models with access to SEC EDGAR for public company filings, financial data, and XBRL facts. It includes tools for company lookup, filing retrieval, XBRL data extraction, and full-text search, with caching and rate limiting. * Company Lookup (lookup_company): Resolve ticker, CIK, or company name to canonical EDGAR identity; ambiguous names return candidates. * Filing History (list_filings): List filings with form type and date range filters; handles over 1000 filings. * Filing Text (get_filing_text): Fetch filing text by URL, with windowing and stripped iXBRL. * XBRL Concepts (list_concepts): List XBRL tags reported by a company, sorted by frequency. * XBRL Time Series (get_concept): Get time series for a specific XBRL concept. * Company Comparison (compare_concept): Rank companies by an XBRL concept for a period. * Full-Text Search (search_filings): Search EDGAR filings from 2001 onward, with filters. * Cache Stats (cache_stats): Monitor cache hit rate, request count, and bytes downloaded. Notable behaviors: * Auto-rate-limits to SEC's 10 req/s, even under parallel bursts. * Caches per-host according to freshness rules (immutable Archives, 1-hour TTL for data.sec.gov); use ttl=0 to bypass cache. * Requires Python 3.11+.

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 Apple's latest 10-K text" 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 asp53826

Overview Schema Related Servers Score Discussions

Python

Remote

edgar-mcp

An MCP server that gives a model working access to SEC EDGAR — company filings, filing text, and XBRL financial facts.

Python 3.11+ runtime deps

Verification launch kit

Inspect	Published evidence
Strongest result	Warm 10-K reads reach 1.1 ms / 0.00 MB, measured at 138x the cold fetch
Verification	Wire-level request windows, transferred-byte counters, offline fixtures, and burst tests
Failure boundary	Public EDGAR data only; not an investment recommendation or a complete accounting model
Reproduce	`make test && make bench`
Interactive replay	Replay the burst and false cache hit

Evidence contract: a class named RateLimiter or Cache proves nothing by itself. The benchmark measures grants inside a real one-second window and bytes transferred on the wire.

→ Interactive results page — fire a burst of tool calls and watch a full token bucket sail through the limit it was written to enforce, then see what each EDGAR host can actually validate.

EDGAR will happily hand you a 9 MB filing and then throttle you for asking twice. The interesting part of this server is everything between the model and the wire.

Related MCP server: SEC EDGAR MCP

What is actually implemented

ticker, CIK, or company name resolves to an EDGAR identity, with ambiguous names returning candidates instead of a silent wrong guess;
filing history spans EDGAR's overflow files, so companies past ~1000 filings don't get silently truncated to the recent page;
filing text arrives windowed with a next_offset cursor — a 10-K is ~206K characters and does not belong in a context window whole;
inline-XBRL scaffolding is stripped, so extracted text starts at the prose and not at 11K characters of false2025FY0000320193...;
XBRL concepts come back as a time series, with a tag-discovery tool because nobody knows the right us-gaap tag name off the top of their head;
one metric can be ranked across every filer for a period via the frames API;
full-text search covers filings from 2001 onward;
requests are paced under SEC's 10 req/s ceiling even when a model fires a parallel burst of tool calls;
responses are cached per-host by the freshness rule that host actually supports.

flowchart LR
  M["model tool call"] --> R["resolve ticker / CIK / name"]
  R --> C{"cached?"}
  C -->|"Archives: immutable"| D["disk, no network"]
  C -->|"data.sec.gov: TTL fresh"| D
  C -->|"stale or absent"| P["pacer @ 9 req/s"]
  P --> E["EDGAR"]
  E -->|"429 / 5xx"| P
  E --> W["cache write"]
  W --> X["iXBRL strip + window"]
  D --> X
  X --> M

Measured, not implied

Apple M-series, macOS, Python 3.13, live EDGAR. Reproduce with make bench.

Check	Result
Tests passing	32
`companyfacts` cold fetch	3.75 MB / 97 ms
`companyfacts` warm read	0.00 MB / 1.4 ms (68×)
10-K document cold fetch	1.52 MB / 154 ms
10-K document warm read	0.00 MB / 1.1 ms (138×)
`submissions` warm read	0.00 MB / 0.2 ms (755×)
Sustained request rate	9.2 req/s
Peak requests in any 1s window	10 (SEC ceiling: 10)
iXBRL scaffolding removed from a 10-K	11,303 chars
Text extraction throughput	23.4 MB/s
Windows to read a full 10-K @ 40K	6

Both the cache and pacer numbers above are post-fix. The first benchmark run reported a 3.75 MB "cache hit" that was really a full re-download, and 19 requests inside a one-second window against a 10 req/s limit. See DESIGN.md.

Where it loses

Freshness on data.sec.gov is a guess. That host sends no ETag and no Last-Modified, so conditional requests are impossible and freshness falls back to a 1-hour TTL. A filing that lands mid-TTL is invisible until it expires. Pass ttl=0 if you need read-your-writes.
Windowing re-reads, it doesn't range-read. EDGAR honors HTTP Range on Archives (verified: 206, accept-ranges: bytes), but partial HTML can't be parsed reliably, so the whole document is fetched once and windowed from cache. The first call on a large filing pays the full download.
Search is never cached. Results are query-shaped and EDGAR's full-text endpoint offers no validators, so every search is a live round trip against the 9 req/s budget.
The pacer is global. Ten companies queried in parallel serialize at ~9 req/s. Correct, but not fast.
XBRL values are consolidated totals. Dimensional breakdowns (by segment, by geography) exist in the data and this does not surface them.
Full-text search starts at 2001. Older filings are reachable through list_filings, not search_filings.

Verify it

make test    # 32 tests, no network
make bench   # live EDGAR, prints the table above

Setup

SEC requires a User-Agent carrying a real contact address and blocks requests without one. The server refuses to start rather than letting you discover that as a confusing 403 later.

export EDGAR_USER_AGENT="your-project you@example.com"

Build and run the local container over stdio:

docker build -t edgar-mcp:local .
docker run --rm -i \
  -e EDGAR_USER_AGENT="your-project you@example.com" \
  edgar-mcp:local

The image runs as an unprivileged user and writes its EDGAR cache under that user's home directory. Mount /home/edgar/.cache/edgar-mcp if the cache should survive container restarts.

Add to claude_desktop_config.json or .mcp.json:

{
  "mcpServers": {
    "edgar": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/edgar-mcp", "edgar-mcp"],
      "env": { "EDGAR_USER_AGENT": "your-project you@example.com" }
    }
  }
}

Tools

Tool	Purpose
`lookup_company`	ticker / CIK / name → EDGAR identity
`list_filings`	filing history, filtered by form and date
`get_filing_text`	windowed document text, follow `next_offset`
`list_concepts`	which XBRL tags a company actually reports
`get_concept`	time series for one tag
`compare_concept`	one tag ranked across all filers for a period
`search_filings`	full-text search, 2001→
`cache_stats`	hit rate, requests, bytes downloaded

A typical chain is lookup_company → list_filings → get_filing_text, or list_concepts → get_concept when you want numbers rather than prose.

License

MIT

Available Tools

8 tools

cache_statsB

Cache hit rate, request count, and bytes downloaded this session.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It clarifies the scope ('this session') and the metrics reported, implying a read-only operation. However, it does not explicitly state that there are no side effects, nor explain any session lifecycle or reset behavior. Still, it adds meaningful context beyond a bare tool name.

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 a single sentence that lists the three key metrics without any filler. Every word is informative, and it is front-loaded with the primary output (cache hit rate).

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

Completeness3/5

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

The description is adequate for a simple, parameterless stats tool. It names the metrics and the session context. However, it lacks detail on the return format or how 'session' is defined, which could be ambiguous. Given no output schema, a bit more context might help, but it is not critically incomplete.

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?

The tool accepts zero parameters, and the schema provides 100% coverage with no fields to document. The description does not need to explain parameters, and it does not. The baseline for zero parameters is 4.

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 clearly identifies the tool as providing cache hit rate, request count, and bytes downloaded for the current session. It specifies the exact resource (cache statistics) and distinguishes it from sibling tools that deal with concepts, filings, and companies.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool or when to prefer alternatives. It does not mention exclusions or specific scenarios where cache_stats would be appropriate. The description implies it is for monitoring session performance, but this is not explicitly stated.

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

compare_conceptB

Compare one XBRL concept across all filers for a period, ranked by value. Period is CY2023 (annual), CY2023Q1 (duration), or CY2023Q1I (instant).

ParametersJSON Schema

Name	Required	Default
`tag`	Yes
`unit`	No	USD
`limit`	No
`period`	Yes
`taxonomy`	No	us-gaap

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions ranking by value, but does not explain what the output looks like, whether it returns a list of filers and values, how limit affects results, or any other side effects. This is a significant transparency gap for a compare tool.

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 compact and well-structured: the first sentence states the core function, the second provides necessary period constraints. Every sentence contributes meaning with no filler or redundancy.

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

Completeness2/5

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

Given the tool has 5 parameters and no output schema, the description is under-specified. It fails to explain what the result set contains (e.g., filer names, values, ranking), the role of unit and taxonomy, or the effect of limit. This makes it insufficient for an agent to fully understand the tool's behavior.

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

Parameters2/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 for parameter meaning. It explains the 'period' parameter with specific examples, but does not elaborate on 'tag', 'unit', 'limit', or 'taxonomy'. The description adds some value for period, but leaves other parameters unexplained.

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 a specific action: comparing one XBRL concept across all filers, ranked by value. This distinguishes it from sibling tools like list_concepts (listing concepts) and get_concept (retrieving a concept for a single entity). The verb and resource are explicit.

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 period format constraints (CY2023, CY2023Q1, CY2023Q1I), which gives some usage context. However, it does not explicitly state when to use this tool versus alternatives like get_concept or search_filings. Usage guidance is implied rather than explicit.

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

get_conceptC

Time series for one XBRL concept (e.g. Revenues, Assets, NetIncomeLoss) as reported by a company across filings.

ParametersJSON Schema

Name	Required	Default
`tag`	Yes
`limit`	No
`query`	Yes
`taxonomy`	No	us-gaap

TDQS

C2.9/5.0

Behavior2/5

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 say the tool returns a time series across filings, but it does not disclose the return format, pagination behavior, authentication needs, or how errors are handled. This is insufficient for a read tool with no annotations.

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?

The description is a single, front-loaded sentence with no fluff. However, its brevity comes at the cost of important detail, so it is concise but perhaps too sparse for the tool's complexity.

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

Completeness1/5

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

With four parameters, no annotations, and no output schema, the description is far too minimal to allow correct invocation. It does not explain how to specify the company, what the query vs. tag are for, or what the returned time series looks like. Significant gaps remain.

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

Parameters1/5

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 clarify the roles of the four parameters (query, tag, limit, taxonomy). It offers examples of concept names but fails to explain which parameter is the concept tag vs. the query, or how limit and taxonomy affect results.

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 that this tool returns a time series for a single XBRL concept (e.g., Revenues, Assets, NetIncomeLoss) as reported by a company across filings. This specific verb+resource combination distinguishes it well from siblings like list_concepts and compare_concept.

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 implies when to use this tool—when you need a single concept's history over time—but it does not explicitly mention alternatives or exclusions. Sibling tools like compare_concept exist, but no direct guidance is provided on when to prefer one over the other.

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

get_filing_textA

Fetch the text of a filing document from its EDGAR Archives URL. Returns a window; if truncated is true, call again with next_offset.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`limit`	No
`offset`	No

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the transparency burden. It discloses the windowed/paginated behavior and the truncated flag, which is useful. However, it does not mention authentication, rate limits, or error behavior, so it is not exhaustive.

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?

Two sentences: the first states the core purpose, the second explains pagination. No filler, well-structured and front-loaded.

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?

For a tool with no annotations and no output schema, the description covers the essential behavioral contract: how to fetch, paginate, and retry. It lacks details about the response structure beyond 'truncated' and 'next_offset', but is adequate for a simple fetch tool.

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 description coverage is 0%, so the description must add meaning. It does: 'url' is clarified as an EDGAR Archives URL, and 'offset' is implicitly explained through 'next_offset'. 'limit' is only hinted at via 'window', but the context makes it understandable.

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 fetches the text of a filing document from its EDGAR Archives URL. The verb 'Fetch' and the resource 'text of a filing document' make the purpose specific and distinct from sibling tools like list_filings or lookup_company.

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 implies usage context: call this when you have a filing document's EDGAR Archives URL and need its text. It also provides pagination guidance ('if truncated is true, call again with next_offset'), but does not explicitly mention exclusions or alternative tools.

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

list_conceptsA

List the XBRL tags a company actually reports, most-reported first. Use this to find the right tag before calling get_concept.

ParametersJSON Schema

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

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description must carry transparency. It discloses that the tool returns only tags the company 'actually reports' (as opposed to standard tags) and that they are ordered 'most-reported first.' This adds behavioral context beyond the basic 'list' semantics. However, it does not mention potential rate limits, pagination, or auth requirements, but for a simple list operation the level of detail is adequate.

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 two sentences long, front-loaded with the core purpose, and every sentence adds value. There is no redundancy or fluff. It is appropriately sized for a simple list tool.

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

Completeness2/5

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

While the description covers purpose and usage, it omits any explanation of the two parameters against a schema with zero descriptions. The agent will not know what 'query' and 'contains' should contain, nor what the returned data looks like (no output schema). Given the tool's simplicity, this makes the description incomplete for reliable selection and invocation.

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

Parameters2/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 by explaining parameters. It does not mention 'query' or 'contains' at all. The phrase 'a company' vaguely implies query selects the company, but there is no explicit explanation of what the parameter values should be or how 'contains' modifies the search. This is a significant gap for correct invocation.

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 lists XBRL tags a company actually reports, with ordering by frequency. It distinguishes itself from get_concept by explicitly positioning this as the step to find the right tag before invoking get_concept. The verb 'list' and resource 'XBRL tags' are specific and unambiguous.

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?

The description provides direct usage guidance: 'Use this to find the right tag before calling get_concept.' This tells the agent when to use the tool and how it relates to a sibling tool, making the intended workflow explicit. No exclusions are stated, but the context is clear.

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

list_filingsA

List a company's filings, newest first. Filter by form type (10-K, 8-K, DEF 14A, 4, ...) and filing-date range (YYYY-MM-DD).

ParametersJSON Schema

Name	Required	Description	Default
`forms`	No
`limit`	No
`query`	Yes
`since`	No
`until`	No

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It reveals the ordering (newest first) and filtering capabilities, but does not explain the meaning of the required 'query' parameter, how limit/pagination works, or what the response contains. This leaves notable gaps for an agent.

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 two concise sentences, front-loaded with the primary action. Every word contributes information, with no redundancy or irrelevant detail.

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

Completeness3/5

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

With 5 parameters, no annotations, and no output schema, the description covers the core purpose and filters but leaves the required 'query' parameter undefined and does not mention 'limit' or return structure. It is adequate but incomplete for a smooth agent invocation.

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?

The schema has no parameter descriptions, so the description is the sole source of meaning. It explains 'forms' with examples, 'since'/'until' with date format, and implies 'query' is the company identifier. It omits 'limit', but overall it adds substantial semantic value beyond the raw 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 the tool lists a company's filings, newest first, with explicit filtering by form type and date range. The verb 'list' and resource 'filings' are specific, and the 'newest first' adds scope that distinguishes it from related tools like search_filings.

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 when you need to list filings for a specific company, optionally filtered by form type or date range. It does not explicitly mention alternatives or exclusions, but the intended usage is evident from the description.

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

lookup_companyA

Resolve a ticker, CIK, or company name to its EDGAR identity.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the function and input types, but does not reveal any behavioral traits such as read-only nature, potential errors, response format, or limitations. For a tool without annotations, this is insufficient.

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 a single, front-loaded sentence that effectively communicates the tool's purpose with no wasted words. It is appropriately sized for a simple lookup tool.

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

Completeness3/5

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

The description is adequate for a simple lookup, but it lacks details on the return value ('EDGAR identity' is vague) and error behavior. Since there is no output schema to clarify this, the description leaves a noticeable gap in completeness.

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?

The description adds meaningful context to the single 'query' parameter by specifying acceptable inputs (ticker, CIK, or company name) beyond what the schema provides (which has no description). It clarifies the expected format, though it could also mention output details.

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's purpose: to resolve a ticker, CIK, or company name to its EDGAR identity. It specifies the verb ('resolve') and the resource ('EDGAR identity'), and the accepted input types distinguish it from sibling tools that deal with concepts or filings.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. The description simply states what the tool does without situating it relative to sibling tools.

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

search_filingsA

Full-text search across EDGAR filings from 2001 onward. Returns matching filings with document URLs.

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes
`forms`	No
`limit`	No
`since`	No
`until`	No

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It adds valuable context by disclosing the 2001-onward restriction and the return of document URLs, but does not cover pagination, rate limits, or explicit read-only nature, leaving gaps in behavioral disclosure.

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 concise: two sentences with no filler, directly stating the action and result. It is front-loaded with the core purpose and efficiently conveys essential information.

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

Completeness2/5

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

For a 5-parameter search tool with no output schema, the description is under-specified. It omits parameter semantics, return structure details beyond 'document URLs', and any usage caveats, making it insufficient for an agent to invoke the tool correctly without additional inference.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no explanation for the 5 parameters (q, forms, limit, since, until). It fails to compensate for the missing schema descriptions, leaving parameter meaning entirely to inference from parameter names.

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 EDGAR filings' with a specific verb and resource, and distinguishes from siblings like list_filings by emphasizing keyword-based search. It also specifies the date range (2001 onward) and output (document URLs), making the tool's purpose unambiguous.

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 implies the tool is for keyword-based searching of filings, providing clear context. However, it does not explicitly mention alternatives or when not to use this tool, so it lacks the exclusions that would earn a 5.

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.

8 tool updatesv0.1.0Jul 31, 2026
- First observedcache_stats
- First observedcompare_concept
- First observedget_concept
- First observedget_filing_text
- First observedlist_concepts
- First observedlist_filings
- First observedlookup_company
- First observedsearch_filings

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct purpose: listing concepts, resolving companies, listing filings, fetching filing text, retrieving concept time series, searching full-text, comparing concepts, and cache statistics. No two tools appear to overlap in function, making selection unambiguous.

Naming Consistency4/5

Most tools follow the verb_noun pattern (list_concepts, lookup_company, get_filing_text, search_filings, compare_concept). The only deviation is cache_stats, which uses a noun_noun form and lacks a verb, but this is a minor inconsistency in an otherwise coherent naming scheme.

Tool Count5/5

With 8 tools, the server is well-scoped for SEC EDGAR data access. Each tool covers a necessary function without redundancy, and the count fits comfortably within the ideal range for a domain-specific MCP server.

Completeness5/5

The tool surface provides a complete read-only workflow: company resolution, filing discovery, full-text search, XBRL concept retrieval, and cross-company comparison. No obvious gaps exist for typical EDGAR use cases, and cache_stats adds operational insight.

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

Edgar A
io.github.pipeworx-io
EDGAR MCP — SEC EDGAR public APIs (free, no auth)
Government Data Finance Open Data
462
sec A
io.github.pipeworx-io
SEC MCP — SEC EDGAR public APIs (free, no auth)
Government Data Finance Open Data
342
Sec Xbrl A
io.github.pipeworx-io
SEC XBRL MCP — wraps SEC EDGAR XBRL API (data.sec.gov)
Finance Government Data
392
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

edgar-mcp
Finance Government Data
mcpwright
A
license
A
quality
B
maintenance
MCP server providing read-only access to SEC EDGAR filings, allowing LLMs to look up companies, search filings, and retrieve securities offering data.
Updated 17 days ago (2026-08-20 18:04 UTC)
3
1
MIT
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
northbridge-diligence
Finance Open Data
chidrupa99
A
license
A
quality
B
maintenance
An MCP server that wraps SEC EDGAR APIs to provide company financial data, screening metrics, and disclosure signals for investment diligence, with every figure traced to its source filing.
Updated a month ago (2026-08-02 04:10 UTC)
8
MIT
edgar-mcp
Government Data Finance Open Data
GeekLad
A
license
Not graded
quality
C
maintenance
MCP server for SEC EDGAR data, providing tools to look up companies, retrieve filings and documents, and access XBRL financial facts.
Updated a month ago (2026-08-02 22:33 UTC)
86
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/asp53826/edgar-mcp'

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