SEC EDGAR MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity: get_company_facts retrieves all financial facts, get_company_filings focuses on filing documents, get_financial_metric tracks a specific metric over time, get_industry_metric provides aggregated industry data, list_common_metrics lists available metrics, and search_companies finds company identifiers. The descriptions clearly differentiate these functions, preventing misselection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as get_company_facts, get_company_filings, get_financial_metric, get_industry_metric, list_common_metrics, and search_companies. This predictable naming convention enhances readability and usability across the tool set.
Tool Count5/5
With 6 tools, the server is well-scoped for SEC EDGAR data access, covering key operations like retrieving company facts, filings, metrics, industry data, metric listings, and company searches. Each tool earns its place without being overwhelming or insufficient for the domain.
Completeness4/5
The tool set provides strong coverage for SEC EDGAR data retrieval, including company-specific and industry-level financial data, filings, and search capabilities. A minor gap exists in update or delete operations, but these are not typical for a read-only data source like SEC filings, so agents can work effectively with the provided tools.
Average 3.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 carries the full burden of behavioral disclosure. It states the tool returns financial facts from filings, which implies a read-only operation, but does not cover aspects like rate limits, authentication needs, error handling, or pagination. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second elaborates on the return values. Every sentence earns its place by adding value without redundancy, making it efficient and well-structured.
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?
Given the tool's complexity (read operation with 2 parameters, no output schema), the description is minimally adequate. It explains what the tool does and returns, but lacks details on behavioral traits (e.g., rate limits) due to no annotations and no output schema. It meets basic needs but has clear gaps for effective agent use.
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 100%, so the schema fully documents the parameters ('company' and 'taxonomy'). The description adds no additional meaning beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline is 3, as the description does not compensate but also does not detract.
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 states the tool's purpose: 'Get all XBRL financial facts for a company' specifies the verb (get) and resource (XBRL financial facts), and 'Returns revenues, assets, liabilities, and other financial metrics from filings' elaborates on the output. It distinguishes from siblings like 'get_financial_metric' (single metric) and 'get_company_filings' (filings rather than facts), but does not explicitly contrast them, so it's not a 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_financial_metric' for single metrics or 'list_common_metrics' for metric definitions, nor does it specify prerequisites or exclusions. Usage is implied by the purpose but 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 provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'Returns 10-K, 10-Q, 8-K, and other filing types with dates and links,' which gives some output context, but lacks details on permissions, rate limits, error handling, or whether it's read-only. For a tool with no annotations, this is a significant gap in 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 concise and front-loaded: it starts with the core purpose and follows with key details in a single, efficient sentence. Every word earns its place, with no redundancy or unnecessary elaboration.
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?
Given no annotations and no output schema, the description is moderately complete for a read operation. It specifies the resource (SEC filings) and return types, but lacks details on output format, pagination, or error scenarios. For a tool with 3 parameters and no structured safety hints, it should do more to compensate.
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 100%, so the schema already documents all parameters (company, formType, limit) thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as examples or edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.
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 states the tool's purpose: 'Get recent SEC filings for a company' with specific filing types listed (10-K, 10-Q, 8-K). It distinguishes from siblings like get_company_facts or get_financial_metric by focusing on filings rather than facts or metrics. However, it doesn't explicitly differentiate from all siblings (e.g., search_companies might also involve company data).
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like get_company_facts for structured data or search_companies for broader searches, nor does it specify prerequisites or exclusions. Usage is implied but 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 provided, the description carries the full burden of behavioral disclosure. It describes the core function but lacks details on permissions, rate limits, data freshness, error handling, or output format (e.g., time series structure). For a tool with 3 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
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, efficient sentence that front-loads the purpose with clarifying examples. Every word earns its place, with no redundancy or unnecessary elaboration.
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?
Given 3 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It covers the what and why but lacks behavioral context (e.g., output format, error cases) and explicit sibling differentiation, which would be needed for full completeness in this context.
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 100%, so the schema already documents all parameters (company, metric, taxonomy). The description adds value by providing examples of metrics (Revenue, Assets, NetIncome) and hinting at the 'history' aspect, but doesn't elaborate on parameter interactions or constraints beyond what's in the schema.
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 states the verb 'Get' and the resource 'financial metric's history for a company', with examples (Revenue, Assets, NetIncome over multiple years) that specify the scope. It distinguishes from siblings like get_company_facts (general facts) or get_company_filings (filings) by focusing on metric history, but doesn't explicitly contrast with get_industry_metric (industry-level) or list_common_metrics (list of metrics).
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 usage by mentioning 'over multiple years', suggesting it's for historical trend analysis, but provides no explicit guidance on when to use this tool versus alternatives like get_company_facts (which might include similar data) or list_common_metrics (for discovering metrics). No exclusions or prerequisites are 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions aggregation but doesn't specify how metrics are aggregated (e.g., sum, average, median) or any limitations like rate limits, data freshness, or error handling. For a tool with 5 parameters and no annotations, this leaves significant behavioral gaps, though it does hint at industry-wide scope.
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 sentences that are front-loaded and waste-free. The first sentence states the core purpose, and the second adds practical context. Every word earns its place, making it easy to parse quickly without unnecessary elaboration.
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?
Given 5 parameters, no annotations, and no output schema, the description is incomplete. It covers the high-level purpose and usage hint but lacks details on aggregation behavior, return format, or error cases. For a tool of this complexity, more context is needed to fully guide an agent, though it meets a minimal viable threshold.
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 100%, so the schema fully documents all 5 parameters with clear descriptions and defaults. The description adds minimal value beyond the schema, only implying that parameters relate to industry aggregation without detailing semantics like how 'limit' affects results. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with additional insights.
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 states the action ('Get') and resource ('financial metric aggregated across all companies'), making the purpose understandable. It distinguishes from siblings like 'get_company_facts' by focusing on industry-wide aggregation rather than company-specific data. However, it doesn't specify the exact aggregation method (e.g., sum, average), leaving some ambiguity.
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 some guidance by stating 'Useful for industry comparisons,' which implies when to use this tool. However, it doesn't explicitly mention when NOT to use it or name alternatives like 'get_financial_metric' (which might be for individual companies). The context is implied but lacks explicit exclusions or comparisons to sibling tools.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists metrics, implying a read-only operation, but doesn't cover aspects like whether it requires authentication, has rate limits, returns paginated results, or what the output format looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 very concise and well-structured, consisting of two sentences that directly state the purpose and usage without any wasted words. It's front-loaded with the core action and efficiently adds a helpful tip, making it easy to understand quickly.
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?
Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is adequate but not complete. It covers the basic purpose and a usage hint, but lacks details on behavioral traits like output format or operational constraints. For a simple listing tool, this is minimally viable but could be improved with more context.
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?
The input schema has 100% description coverage, with the 'category' parameter fully documented in the schema itself. The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining the categories further or giving examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 states the tool's purpose: 'List commonly used XBRL financial metrics with their tags.' It specifies the verb ('List') and resource ('XBRL financial metrics with their tags'), making the action and target explicit. However, it doesn't differentiate from siblings like 'get_financial_metric' or 'get_industry_metric', which might retrieve specific metrics rather than list common ones, so it's not a perfect 5.
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 implied usage guidance: 'Helpful for finding the right metric name.' This suggests using the tool when you need to discover or identify metrics, but it doesn't explicitly state when to use this tool versus alternatives like 'get_financial_metric' or 'get_industry_metric', nor does it mention exclusions or prerequisites. The guidance is useful but not comprehensive.
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 of behavioral disclosure. It describes what the tool does (search and return matching companies with specific fields) but doesn't mention important behavioral aspects like rate limits, authentication requirements, error conditions, or pagination behavior. The description is accurate about the tool's function but lacks operational context.
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 perfectly concise with two sentences that each earn their place. The first sentence explains the purpose and parameters, the second explains the return values. There's no wasted language and the information is front-loaded effectively.
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 search tool with 2 parameters (100% schema coverage) and no output schema, the description provides good context about what the tool does and what it returns. However, without annotations and with no output schema, it could benefit from more detail about return format structure or error handling. The description covers the essential purpose and output but leaves some operational details unspecified.
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 100%, so the schema already fully documents both parameters. The description mentions searching 'by name or ticker' which aligns with the query parameter description, but adds no additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.
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 specific action ('Search for companies'), the resource ('companies'), and the purpose ('to find their CIK'). It distinguishes from siblings by focusing on search functionality rather than retrieving facts, filings, or metrics. The description explicitly mentions what information is returned (CIK, ticker, name).
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 for when to use this tool: when searching for companies by name or ticker to obtain CIK information. It doesn't explicitly mention when not to use it or name specific alternatives among the sibling tools, but the purpose is sufficiently distinct from siblings like get_company_facts or get_company_filings that the appropriate usage is implied.
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:

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

Score Badge

Copy to your README.md:

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

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/shawndrake2/mcp-sec-edgar'

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