Skip to main content
Glama
NiharKalsekar099

SEC EDGAR MCP Server

by NiharKalsekar099
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

SEC EDGAR MCP Server

A Model Context Protocol (MCP) server that exposes endpoints to retrieve SEC company profiles, historic filing listings, and structured XBRL financial statements directly into AI environments. Built with Python, FastMCP, and edgartools.

⚙️ Configuration & Setup

  1. Clone the Repository:

    git clone https://github.com/MakAcp/sec-insight-mcp.git
cd sec-insight-mcp

  2. Create and Activate Virtual Environment:

    • Windows:

      python -m venv .venv
.\.venv\Scripts\activate

    • macOS/Linux:

      python3 -m venv .venv
source .venv/bin/activate

  3. Install Dependencies: Install the project in editable mode so dependencies listed in pyproject.toml are correctly resolved:

    pip install -e .

  4. Configure Environment: Create a .env file in the root directory (refer to .env.example):

    SEC_EDGAR_USER_AGENT="YourName (your.email@example.com)"

    Note: SEC compliance requires a valid name and email address in the User-Agent header. Program requests will be blocked if this is not provided.

Related MCP server: SEC EDGAR MCP

🛠️ Run & Test

  • Run the MCP Server (Stdio Mode):

    • Windows:

      .\.venv\Scripts\python server.py

    • macOS/Linux:

      python server.py

  • Run the Automated Test Suite:

    • Windows:

      .\.venv\Scripts\python tests/run_tests.py

    • macOS/Linux:

      python tests/run_tests.py

📖 MCP Tools Legend

Below are the tool endpoints exposed by the server for integration with Cursor, Claude Desktop, or other MCP clients:

1. health_check

Perform a connection and compliance check on the server.

  • Parameters: None

  • Returns: str (Confirmation message containing the active SEC User-Agent).

2. get_company_profile

Retrieve administrative and registration metadata for a target company.

  • Parameters:

    • ticker_or_cik (required, str): The company's ticker symbol (e.g. AAPL, SOFI) or 10-digit CIK (e.g. 0000320193).

  • Returns: str (Markdown profile table containing Official Name, CIK, Tickers, Industry SIC, shares outstanding, filer category, and addresses).

3. list_filings

Search and list recent filings submitted by a company. Supports row-based pagination (capped at max 20 pages / 2,000 filings to prevent infinite iteration loops).

  • Parameters:

    • ticker_or_cik (required, str): The ticker symbol or CIK.

    • form (optional, str): Filter by form type (e.g. 10-K, 10-Q, 8-K, 4). Defaults to no filter.

    • limit (optional, int): Max number of filings per page to return (default: 10, max: 100).

    • page (optional, int): Page number to retrieve (default: 1, max safety cap: 20).

    • year (optional, int): Filter by filing calendar year.

  • Returns: str (Markdown table listing Accession Numbers, Dates, Forms, Period of Report, formatted File Sizes, and XBRL structures with pagination metadata).

4. get_financial_statements

Extract the Consolidated Balance Sheets, Income Statements (Operations), and Cash Flow Statements from a company's XBRL report.

  • Parameters:

    • ticker_or_cik (optional, str): The ticker or CIK. If provided alone, extracts statements from the latest report.

    • accession_number (optional, str): Specific 20-character accession number (e.g., 0000320193-25-000079). If provided, extracts statements from that specific filing.

  • Returns: str (Concatenated Markdown sheets detailing account lines, values, and comparative periods).

5. get_filing_section

Extract a specific text section (e.g. Item 1A Risk Factors, Item 7 MD&A, Item 1 Business Overview) from a target filing, supporting character chunk-based pagination (capped at max 10 pages / 120,000 characters to prevent infinite iteration loops).

  • Parameters:

    • ticker_or_cik (optional, str): The ticker or CIK. If provided alone, extracts section from the latest 10-K or 10-Q filing.

    • accession_number (optional, str): Specific 20-character accession number.

    • section_name (optional, str): The name/ID of the section to retrieve (e.g., Item 1A, Item 7, Item 1). Defaults to Item 1A.

    • page (optional, int): Page number of the text chunk to retrieve (default: 1, max safety cap: 10).

    • page_size (optional, int): Number of characters per page (default: 12000, min: 1000, max: 30000).

  • Returns: str (Markdown-formatted text section chunk, with pagination info banner).

📖 MCP Prompts Legend

Below are the custom prompt templates registered on the server for user invocation:

1. compare_competitors

Renders a structured plan to perform a side-by-side comparative analysis of two competing companies.

  • Parameters:

    • ticker_a (required, str): The first company's ticker symbol.

    • ticker_b (required, str): The second company's ticker symbol.

  • Flow: Instructs the client model to retrieve profiles, Business Overviews (Item 1), and financial statements for both companies, compiling a comparative markdown table covering segment overlay, revenue, strategic advantages, and leverage.

2. audit_investment_risks

Directs the client model to act as a Senior Risk Analyst and perform a comprehensive risk and financial health audit on a target company.

  • Parameters:

    • ticker (required, str): The company's ticker symbol.

  • Flow: Instructs the model to retrieve the company's profile, Item 1A Risk Factors, and financial statements to output an Executive Summary risk assessment, top 3 operational hazards, financial health check, and management-to-balance-sheet red flags evaluation.

3. analyze_earnings_quality_ttm

Directs the client model to act as a Forensic Accountant and audit the quality of earnings of a company over the Trailing Twelve Months (TTM).

  • Parameters:

    • ticker (required, str): The company's ticker symbol.

  • Flow: Instructs the model to retrieve the company's quarterly financial statements, extract Net Income and Operating Cash Flow (OCF) for the last 4 available quarters, calculate the TTM totals and the TTM Quality of Earnings Ratio (TTM OCF / TTM Net Income), and analyze working capital drivers/non-cash items causing gaps.

🔌 Client Integration

1. Claude Desktop

Add the following configuration to your %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "sec-edgar": {
      "command": "/path/to/your/project/.venv/bin/python",
      "args": [
        "/path/to/your/project/server.py"
      ],
      "env": {
        "SEC_EDGAR_USER_AGENT": "YourName (your.email@example.com)"
      }
    }
  }
}

(On Windows, use backslashes for paths and point to Scripts\python.exe instead of bin/python)

2. Cursor

To configure the server in Cursor Settings:

  1. Go to Settings -> Features -> MCP.

  2. Click + Add New MCP Server.

  3. Fill in the details:

    • Name: sec-edgar

    • Type: command

    • Command: /path/to/your/project/.venv/bin/python /path/to/your/project/server.py (or local Windows equivalent path)

  4. Click Save.

3. Codex

Add the following configuration to your global Codex configuration file (located at %USERPROFILE%\.codex\config.toml on Windows) or to the local project-specific .codex/config.toml file:

[mcp_servers.sec-edgar]
command = "/path/to/your/project/.venv/bin/python"
args = ["/path/to/your/project/server.py"]
env = { SEC_EDGAR_USER_AGENT = "YourName (your.email@example.com)" }

Available Tools

13 tools
edgar_companyA

Use this as the starting point for any company-level question. Returns profile, financials, recent filings, and ownership data in one call. Control what's included with the 'include' parameter.

Examples:

  • Company overview: identifier="AAPL"

  • Financials only: identifier="MSFT", include=["financials"], periods=8

  • Full analysis: identifier="AAPL", include=["profile", "financials", "filings", "ownership"]

ParametersJSON Schema
NameRequiredDescriptionDefault
annualNoDeprecated. Use 'period' instead. Annual (true) or quarterly (false) financials
periodNoPeriod type: 'annual', 'quarterly', or 'ttm' (trailing twelve months)annual
includeNoData to include. Default: profile, financials, filings
periodsNoNumber of financial periods (default 4)
identifierYesCompany ticker (AAPL), CIK (320193), or name (Apple Inc)

TDQS

A4/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It describes the tool as returning data (profile, financials, etc.) and how to control inclusion, implying a read operation. It does not explicitly state read-only, but the behavior is transparent.

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 well-structured, front-loaded with the primary purpose, and includes concise examples. Each sentence adds value, though it could be slightly more terse without losing clarity.

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

Completeness4/5

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

Given no output schema, the description adequately explains the returned data types and customization. It covers all key parameters and usage scenarios, though it omits error handling or limits.

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 coverage is 100% with descriptions. The description adds value through examples (e.g., 'identifier="AAPL"', 'include=["financials"]') and explains default behavior, improving parameter understanding beyond 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 tool is the starting point for company-level questions, returning profile, financials, filings, and ownership. It distinguishes itself from siblings as a comprehensive entry point, but does not explicitly contrast with each sibling.

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?

Explicitly says 'Use this as the starting point for any company-level question,' providing clear when-to-use guidance. However, it does not specify when not to use or provide alternative tools for specific cases.

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

edgar_compareA

Use this to compare companies side-by-side on financial metrics, or analyze an industry sector with automatic peer selection.

Examples:

  • Compare companies: identifiers=["AAPL", "MSFT", "GOOGL"]

  • Industry analysis: industry="software", limit=5

  • Bank comparison: identifiers=["JPM", "BAC", "WFC"], metrics=["revenue", "net_income", "assets"]

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax companies for industry comparison (default 5)
annualNoAnnual (true) or quarterly (false)
metricsNoMetrics to compare (default: revenue, net_income)
periodsNoNumber of periods (default 3)
industryNoOR select industry for automatic peer selection
identifiersNoCompanies to compare (2-10 tickers/CIKs)

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description bears full burden. It describes the tool's action but omits behaviors like conflict handling when both 'identifiers' and 'industry' are provided, output format, or data freshness. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is succinct: a single sentence defining the tool followed by three concise examples. No filler, front-loaded with core functionality.

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 6-parameter tool with two major modes, the description covers the key use cases. It lacks mention of conflict resolution between inputs and output details (no output schema), but is otherwise complete for the primary scenarios.

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 coverage is 100% with descriptions for all 6 parameters. The description adds real usage examples but does not clarify mutual exclusivity of 'identifiers' and 'industry' or explain parameter interactions beyond schema. Baseline 3 is appropriate.

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 explicitly states the tool compares companies on financial metrics or analyzes an industry sector with peer selection. Examples clearly distinguish it from siblings like edgar_company (single company) and edgar_screen (filtering).

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 use cases with examples (company comparison vs. industry analysis). It does not explicitly exclude conflicting inputs or name alternatives but the usage contexts are well-defined.

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

edgar_filingA

Use this to examine any SEC filing. Returns structured context: what the filing is, key data, and available next steps. If the filing has a typed data object (10-K, 10-Q, 8-K, Form 4, 13F, DEF 14A, etc.), returns extracted financials, sections, ownership, transactions, etc.

Two ways to specify the filing:

  1. By company + form type: identifier="AAPL", form="10-K" (gets the latest)

  2. By accession number or URL: input="0000320193-23-000077"

Examples:

ParametersJSON Schema
NameRequiredDescriptionDefault
formNoForm type (10-K, 10-Q, 8-K, DEF 14A, 4, 13F-HR, etc.). Used with 'identifier'.
inputNoAccession number or URL containing an accession number (alternative to identifier+form)
detailNoDetail level for context output (default: standard)standard
identifierNoCompany ticker (AAPL), CIK (320193), or name. Used with 'form' to get the latest filing.

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the tool's functionality and return types, but does not disclose behavioral traits like authentication needs, rate limits, or error handling for invalid inputs.

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 well-organised with bullet points and examples, making it easy to read. While slightly lengthy due to examples, it remains efficient and front-loaded with purpose.

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?

With no output schema, the description adequately covers the tool's purpose, parameter usage, and typical return content. It lacks mention of error responses or edge cases, but is otherwise complete.

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 100%, but the description adds value beyond the schema by explaining parameter combinations, the detail parameter's effect, and providing concrete examples.

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 examines any SEC filing and returns structured context. It provides examples and mentions key data types, but does not explicitly differentiate from sibling tools like edgar_read.

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 details two ways to specify a filing with examples, offering clear context on parameter usage. However, it does not specify when not to use this tool or mention alternatives.

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

edgar_fundA

Use this for mutual fund, ETF, BDC, and money market fund analysis. Supports fund lookup, portfolio holdings, money market yields, and BDC investments.

Actions: lookup (find fund by ticker/CIK), search (by name), portfolio (NPORT holdings), money_market (yields/NAV), bdc_search, bdc_portfolio.

Examples:

  • Fund lookup: action="lookup", identifier="VFINX"

  • Fund search: action="search", query="Vanguard 500"

  • Fund portfolio: action="portfolio", identifier="VFINX"

  • Money market: action="money_market", identifier="VMFXX"

  • BDC search: action="bdc_search", query="Ares"

  • BDC portfolio: action="bdc_portfolio", identifier="ARCC"

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return (default 20, max 50)
queryNoSearch text for fund or BDC name
actionYesThe action to perform
identifierNoFund ticker, series ID (S000XXXXX), class ID (C000XXXXX), or CIK

TDQS

A4.3/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden. It transparently lists all actions with examples, making the tool's behavior clear. It does not disclose error handling or rate limits, but the read-only nature is inferred from the actions.

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 efficient and front-loaded with the tool's purpose. It uses a list of action types and examples, making it scannable. However, some minor redundancy could be trimmed.

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 adequately covers the available actions and example usage. However, it lacks details on return format, pagination (limit parameter), and error cases. Given no output schema, more context on response would improve completeness.

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

Parameters5/5

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by providing concrete examples for each action and parameter combination, demonstrating usage beyond the schema's simple descriptions.

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 is for mutual fund, ETF, BDC, and money market fund analysis, with specific actions listed. It distinguishes from sibling tools like edgar_company and edgar_filing by focusing solely on fund-related data.

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 explicitly says 'Use this for ... fund analysis,' providing clear context for when to invoke the tool. It does not explicitly mention when not to use it or point to alternatives, but the sibling list implies differentiation.

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

edgar_monitorA

Use this to see what was just filed with the SEC. Returns the latest filings from today's live feed, updated every few minutes. Filter by form type to track specific events.

Examples:

  • All latest: (no parameters)

  • Today's 8-Ks: form="8-K"

  • Insider trades: form="4"

  • Latest 10-Ks: form="10-K"

  • More results: limit=50

ParametersJSON Schema
NameRequiredDescriptionDefault
formNoFilter by form type (e.g., '8-K', '4', '10-K', '10-Q', '13F-HR')
limitNoMax filings to return (default 20, max 100)

TDQS

A4.2/5.0
Behavior4/5

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

Discloses that feed is updated every few minutes, returns latest filings, and limit has maximum of 100. With no annotations, this provides sufficient behavioral insight for a non-destructive monitoring 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?

Extremely concise with a clear structure: one-line purpose, update frequency, then bulleted examples. Every sentence adds value without redundancy.

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 simple monitoring tool with no output schema, the description adequately covers key aspects (filtering, limit, update cadence). Lacks explicit return format, but examples imply list of filings; sufficient for this complexity.

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 coverage is 100%, so description adds marginal value beyond schema. Examples show valid form values and default/max for limit, but does not provide new semantic information beyond what schema already includes.

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 returns latest SEC filings from today's live feed, using specific verbs (see, returns). It distinguishes from siblings by focusing on real-time monitoring rather than historical search or company-specific tools.

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?

Provides clear usage guidance with examples for common scenarios (all filings, 8-Ks, insider trades, etc.). Lacks explicit when-not-to-use or comparisons with sibling tools, but the context strongly implies its purpose.

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

edgar_notesA

Drill into the notes and disclosures behind financial statement numbers. Use this when you need to explain WHY a number is what it is — debt terms, revenue recognition policies, lease schedules, contingencies, etc.

Returns the note's narrative text, which statement line items it explains, and structured table data.

Examples:

  • What does Apple's debt note say? topic="debt", identifier="AAPL"

  • Revenue recognition policy: topic="revenue", identifier="MSFT"

  • All notes overview: identifier="TSLA" (no topic = table of contents)

ParametersJSON Schema
NameRequiredDescriptionDefault
formNoFiling form type (default: 10-K). Use 10-Q for quarterly notes.10-K
topicNoNote topic to search for (e.g., 'debt', 'revenue', 'leases', 'contingencies'). Omit for table of contents.
detailNoDetail level: minimal (titles only), standard (context + tables), full (includes DataFrame data)standard
identifierYesCompany ticker (AAPL), CIK (320193), or name

TDQS

A4.4/5.0
Behavior4/5

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

Describes what the tool returns: narrative text, statement line items it explains, and structured table data. Also explains detail levels (minimal, standard, full). No annotations provided, so the description carries full burden; it adequately discloses behavior without contradictions.

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 short paragraphs plus bullet-style examples. Every sentence adds value, with the first sentence immediately stating purpose. No redundancy or unnecessary detail.

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

Completeness4/5

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

Given the tool has 4 parameters, no output schema, and simple return structure, the description covers return types (narrative, tables) and detail levels. Missing are error cases and rate limits, but for a read-only document retrieval tool this is acceptable.

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 coverage is 100%, so baseline is 3. The description adds value by providing examples of topic values (debt, revenue, leases) and clarifying that omitting topic gives a table of contents. This enriches the parameter meaning beyond the schema alone.

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 uses a specific verb 'drill into' and identifies the resource as 'notes and disclosures' behind financial statement numbers. It clearly distinguishes from sibling tools like edgar_read or edgar_filing by focusing on explanatory notes.

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?

Explicitly states when to use: 'when you need to explain WHY a number is what it is' with concrete examples (debt terms, revenue recognition). Does not explicitly state when not to use, but the context and examples imply it is for notes, not for raw filings or comparisons.

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

edgar_ownershipA

Use this for insider trading activity (Form 4) or institutional fund portfolios (13F). For companies, use analysis_type="insiders". For funds/institutions, use analysis_type="fund_portfolio" with the fund's CIK.

Examples:

  • Insider trades: identifier="AAPL", analysis_type="insiders"

  • Berkshire portfolio: identifier="1067983", analysis_type="fund_portfolio"

  • Portfolio changes: identifier="1067983", analysis_type="portfolio_diff"

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNoLookback period for insider transactions (default 90)
limitNoMax results (default 20)
identifierYesCompany ticker/CIK (for insiders) OR fund/institution CIK (for fund_portfolio/portfolio_diff)
analysis_typeYesinsiders=Form 4 insider trades, fund_portfolio=13F holdings, portfolio_diff=quarter-over-quarter changes

TDQS

A3.9/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose behavioral traits such as read-only nature, error handling, rate limits, or what happens with invalid identifiers. Only usage behavior is implied.

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 short paragraphs, front-loaded with purpose, followed by succinct examples. Every sentence is meaningful and no wasted words.

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 output schema, description does not explain return format, pagination, or error states. Adequate for a simple tool but could be more complete regarding expected output.

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 coverage is 100%, so schema already documents parameters. The description adds value by explaining the relationship between identifier and analysis_type with examples, but does not significantly extend beyond schema descriptions.

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 is for insider trading (Form 4) and institutional fund portfolios (13F), with specific analysis_type values. It distinguishes from sibling tools by focusing on these specific data sources.

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?

Explicitly tells when to use (insider trades or fund portfolios) and provides examples for each use case, including correct identifier format and analysis_type. No explicit when-not-to, but the examples serve as clear guidance.

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

edgar_proxyA

Use this for CEO compensation, executive pay, and corporate governance questions. Extracts compensation tables, pay-vs-performance metrics, and governance data from DEF 14A proxy statements.

Examples:

  • CEO pay: identifier="AAPL"

  • Compare pay: identifier="MSFT"

  • Prior year: identifier="AAPL", filing_index=1

ParametersJSON Schema
NameRequiredDescriptionDefault
identifierYesCompany ticker, CIK, or name
filing_indexNoWhich proxy filing to use (0=latest, 1=previous, etc.)

TDQS

A4.2/5.0
Behavior3/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. It discloses the kind of data extracted (tables, metrics, governance data) but does not mention that the tool is read-only, any required permissions, rate limits, or response format. The examples suggest it retrieves static data, but this is implicit.

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, with a clear purpose statement followed by practical examples. Every sentence serves a purpose: the first defines the domain, the second lists extracted items, and examples show parameter usage. No redundant or irrelevant content.

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

Completeness4/5

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

Given the tool has two parameters (both well-documented in schema) and no output schema, the description adequately covers the input. However, it could be more complete by describing the output format or indicating if it returns structured data or raw text. The examples give hints but not a full specification.

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 input schema has 100% description coverage, so the baseline is 3. The description adds value by clarifying the 'filing_index' parameter with '0=latest, 1=previous' in examples, which is not in the schema description. It also demonstrates usage patterns for 'identifier' with tickers like AAPL and MSFT.

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 is for CEO compensation, executive pay, and corporate governance questions, with specific actions like extracting compensation tables and pay-vs-performance metrics. This distinguishes it from siblings like 'edgar_monitor' or 'edgar_company' by focusing exclusively on proxy statements.

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 tells when to use the tool (compensation and governance questions) and provides concrete examples for CEO pay and compare pay. However, it does not explicitly state when not to use it or mention alternative tools for other SEC filings.

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

edgar_readA

Use this to read the text content of specific sections from a filing. Extracts narrative content like risk factors, MD&A, business descriptions, financial tables, and event items.

Use edgar_filing first to identify a filing, then edgar_read to extract its content.

Available sections by form type:

  • 10-K/10-Q: business, risk_factors, mda, financials, controls, legal

  • 20-F: business, risk_factors, mda, financials, directors, shareholders, controls

  • 8-K: items, press_release, earnings

  • DEF 14A: compensation, pay_performance, governance

  • SC 13D/13G: ownership, purpose

  • 13F-HR: holdings, summary

Examples:

  • Read risk factors: identifier="AAPL", form="10-K", sections=["risk_factors"]

  • Read 8-K event: identifier="AAPL", form="8-K", sections=["items"]

  • Read CEO pay: identifier="AAPL", form="DEF 14A", sections=["compensation"]

ParametersJSON Schema
NameRequiredDescriptionDefault
formNoForm type (used with identifier to get most recent)
sectionsNoSections to extract. Use 'summary' for metadata only, 'all' for everything. Available sections depend on form type.
identifierNoCompany identifier (alternative - gets most recent filing of form type)
accession_numberNoFiling accession number (e.g., 0000320193-23-000077)

TDQS

A4.5/5.0
Behavior4/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. It explains the tool extracts narrative content and lists available sections per form type. It implies read-only behavior but does not detail edge cases like conflicting parameters or output format.

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, well-structured with bullet points and examples. Each sentence adds value, and the most critical information is 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?

Given no output schema and no annotations, the description covers the workflow, section availability, and examples. It lacks clarification on behavior when both identifier and accession_number are provided, and does not describe the return format. Overall, it is fairly complete.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3. The description adds significant value by providing a detailed list of available sections per form type, usage guidance for identifier vs accession_number, and examples that clarify param combinations.

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 reads text content of specific sections from a filing, distinguishing it from siblings like edgar_filing (which identifies filings) and edgar_text_search (which searches text). It provides a specific verb and resource, and includes form-specific section lists.

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 explicitly instructs to use edgar_filing first to identify a filing before using edgar_read, and provides examples for different forms. It does not explicitly state when not to use it, 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.

edgar_screenA

Use this to discover or screen companies by industry, exchange, or state. Returns matching companies from SEC reference data — instant results, no API calls. Combine filters to narrow results.

Examples:

  • By industry: industry="software"

  • By SIC code: sic=2834 (pharmaceutical)

  • By exchange: exchange="NYSE"

  • By state: state="DE" (Delaware)

  • Combined: industry="semiconductor", exchange="Nasdaq", limit=20

ParametersJSON Schema
NameRequiredDescriptionDefault
sicNoExact SIC code (e.g., 2834 for pharma, 7372 for software)
limitNoMax companies to return (default 25, max 100)
stateNoUS state code for state of incorporation (e.g., 'DE', 'CA', 'NY')
exchangeNoStock exchange filter
industryNoIndustry keyword to search SIC descriptions (e.g., 'software', 'pharmaceutical', 'banking')

TDQS

A4.4/5.0
Behavior4/5

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

The description states 'instant results, no API calls', which gives insight into performance and dependencies. It also says filters can be combined. Since no annotations exist, the description takes on the burden, and these details help the agent understand behavior. However, it does not mention ordering, pagination, or what happens if no matches are found.

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 well-structured. It starts with a clear purpose sentence, then a note about instant results, followed by five bullet-point examples. Every sentence is informative and earns its place with no redundancy or fluff.

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

Completeness4/5

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

Given 5 optional parameters and no output schema or annotations, the description covers the tool's functionality well. It explains the data source (SEC reference) and shows parameter combinations. However, it could mention the structure of returned results or any limitations, but it is sufficiently complete for an agent to use the tool correctly.

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?

All parameters are documented in the schema with descriptions, but the description adds value by providing concrete examples for each parameter (e.g., sic=2834, industry='software', exchange='NYSE'). It also explains that 'industry' searches SIC descriptions, which is not in the schema. This enhances understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is used to 'discover or screen companies by industry, exchange, or state', and specifies that it returns matching companies from SEC reference data. The examples further reinforce the purpose without ambiguity, and it differentiates from siblings like edgar_search, edgar_company, etc., by focusing on screening rather than searching filings or company details.

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 explicitly says 'Use this to discover or screen companies' and provides context on when to use it. It includes examples of filtering by industry, SIC, exchange, and state, and notes that filters can be combined. However, it does not mention when not to use this tool or point to alternative tools for related tasks, missing some guidance.

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

edgar_text_searchA

Use this to find filings that mention specific topics, products, risks, or events. Searches the actual text content of all SEC filings via EDGAR's full-text search index (EFTS). Different from edgar_search which only searches metadata.

Examples:

  • Topic search: query="artificial intelligence"

  • 8-K events: query="cybersecurity incident", forms=["8-K"]

  • Date range: query="supply chain disruption", start_date="2024-01-01"

  • Company-specific: query="tariff impact", forms=["10-K"], identifier="AAPL"

ParametersJSON Schema
NameRequiredDescriptionDefault
formsNoFilter by form types (e.g., ['10-K', '8-K']). Default: all forms.
limitNoMax results to return (default 20, max 50)
queryYesFull-text search query (searches filing content)
end_dateNoEnd date for filing date range (YYYY-MM-DD)
identifierNoOptional company ticker or CIK to scope results
start_dateNoStart date for filing date range (YYYY-MM-DD)

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It mentions default and max limit (20, max 50) for the limit parameter, which is helpful. However, it fails to disclose other behavioral traits like rate limits, pagination behavior, or any restrictions on query complexity. The description could be more transparent about expected behavior beyond the schema.

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 concise, front-loaded with the main purpose, and uses a bullet list for examples. Every sentence adds value. However, slightly longer than necessary due to the example list, but this is informative.

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 output schema, the description does not explain the return format or what fields are returned per result. For a search tool, the agent needs to know what information is in the response (e.g., filing IDs, excerpts, relevance scores). The description provides good input guidance but lacks output context. Sufficient for basic use but incomplete for complex workflows.

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 coverage is 100%, but the description adds value beyond schema by showing concrete usage examples (e.g., forms, dates, identifier). This helps the agent understand how to combine parameters effectively. The examples demonstrate the semantics well.

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 it searches the actual text content of SEC filings via EDGAR's full-text search index, and explicitly distinguishes from edgar_search which only searches metadata. The verb+resource is specific and differentiates from siblings.

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 explicit usage examples (topic search, 8-K events, date range, company-specific) and explicitly contrasts with edgar_search, telling the agent when to use this tool vs the alternative.

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

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

TDQS

A4.3/5.0
Disambiguation5/5

Each tool targets a distinct aspect of SEC data: monitoring, company profiles, metadata search, full-text search, filing retrieval, section reading, comparison, ownership, trends, company screening, fund analysis, proxy statements, and financial notes. The descriptions clearly differentiate overlapping tools like edgar_search vs. edgar_text_search.

Naming Consistency5/5

All tools follow the consistent pattern 'edgar_<word>' with a mix of nouns and verbs. The naming is predictable and intuitive (e.g., edgar_filing, edgar_read, edgar_compare).

Tool Count5/5

With 13 tools, the set is well-scoped for an SEC filings server. Each tool covers a specific task without overlap, and the count is appropriate for the domain's complexity.

Completeness5/5

The tool set comprehensively covers SEC-related tasks: monitoring, searching, retrieving, reading, comparing, analyzing ownership, trends, screening, fund analysis, proxy, and financial notes. There are no obvious gaps for the intended use case.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • edgar-mcp

    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.
    3
    1
    MIT

  • SEC EDGAR MCP

    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.
    21
    353
    AGPL 3.0

  • sec-edgar-mcp

    guptaprakhariitr
    A
    license
    Not graded
    quality
    D
    maintenance
    Hosted MCP server that gives AI agents real-time access to SEC EDGAR filings search, 10-K/8-K reading, XBRL financial facts, and insider-trade (Form 4) alerts.
    25
    1
    MIT

Latest Blog Posts

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/NiharKalsekar099/sec-insight-mcp'

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