edgar-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![edgar-mcp MCP server](https://glama.ai/mcp/servers/asp53826/edgar-mcp/badges/card.svg)](https://glama.ai/mcp/servers/asp53826/edgar-mcp)

Score Badge

Copy to your README.md:

[![edgar-mcp MCP server](https://glama.ai/mcp/servers/asp53826/edgar-mcp/badges/score.svg)](https://glama.ai/mcp/servers/asp53826/edgar-mcp)

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