Monorepo for SEC EDGAR agent toolkit integrations providing tools for company lookup, SEC filing search, financial data extraction, insider trading analysis, and 8-K event monitoring across multiple LLM frameworks (LangChain, LangGraph, smolagents, Dify, Gradio, mcp-use).
This is a LangChain/agent toolkit, not an MCP server. The evaluation treats the 11 defined tools as if they were MCP tool definitions. Tool definitions show moderate quality: most have descriptions and basic input schemas, but descriptions are often generic, parameter documentation is sparse, output schemas are undocumented, and error handling guidance is absent. No tool has comprehensive parameter validation rules or recovery guidance. Tool names follow verb_noun convention (search_, get_, extract_, analyze_), which is good. However, descriptions lack the LLM-optimization specificity needed for reliable tool selection, e.g., 'Get detailed company information from SEC EDGAR' doesn't explain WHEN to call this vs sec_edgar_cik_lookup or sec_edgar_company_facts. Parameters often lack constraints (enums, min/max, format specs), and no tool documents its output schema. The toolkit is functional for domain specialists but would benefit from tighter descriptions, parameter constraints, and output documentation.
Get recent 8-K material events for a company. Input: CIK number. Output: List of recent 8-K events with descriptions.
Analyze 8-K reports for key events
Look up a company's CIK (Central Index Key) number by name or ticker symbol. Input: company name or ticker. Output: CIK number and company info.
Get XBRL company facts (financial data points). Input: CIK number. Output: All available XBRL facts including revenues, assets, etc.
Get detailed company information from SEC EDGAR. Input: CIK number or ticker. Output: Company details including name, SIC, location, fiscal year end.
Compare financial metrics between two companies. Input: JSON with 'cik1', 'cik2', and 'metrics' list. Output: Side-by-side comparison of requested metrics.
Output schemas not documented. Users cannot predict what fields will be returned or plan downstream tool chaining. Tools like sec_edgar_filing_search, sec_edgar_financial_statements, and sec_edgar_company_facts return complex data structures (lists of filings, financial statements with income/balance/cashflow) but no schema is documented.
Descriptions lack LLM-optimization specificity. Descriptions are generic ('Get detailed company information') and do not explain WHEN to call this tool vs related tools (e.g., when to call sec_edgar_company_info vs sec_edgar_company_facts vs sec_edgar_cik_lookup). LLMs cannot disambiguate without explicit guidance on distinct use cases.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Extract and parse content from a specific SEC filing. Input: Filing URL or accession number. Output: Parsed filing content.
Search for SEC filings by company and form type. Input: JSON with 'cik' and optional 'form_type' (10-K, 10-Q, 8-K, etc.), 'date_from', 'date_to'. Output: List of filings with dates and URLs.
Extract financial statements from 10-K or 10-Q filings. Input: JSON with 'cik' and 'period' (e.g., '2023-Q4' or '2023'). Output: Income statement, balance sheet, and cash flow data.
Get insider trading data (Form 4 filings). Input: JSON with 'cik' and optional 'days_back' (default 90). Output: Recent insider transactions with amounts and dates.
Parse XBRL data for specific financial facts
Parameter constraints missing. Parameters like 'formTypes' (array of form types), 'taxonomy' (e.g., 'us-gaap', 'dei'), and date ranges lack enum constraints or format specifications. Free-form strings invite hallucinated or invalid values (e.g., LLM might pass '10k' instead of '10-K', or malformed dates).
No parameter validation rules or range documentation. Numeric parameters like 'limit' (max results), 'months' (lookback period), and 'year' lack min/max constraints, defaults, or validation guidance. SEC EDGAR APIs have rate limits and data availability windows that should be documented.
Two tools with near-identical names and overlapping functionality: 'sec_edgar_8k_events' vs 'sec_edgar_analyze_8k'. Both accept CIK and limit parameters, and both return 8-K data. LLMs will conflate them and waste reasoning cycles deciding between them. Consolidate into a single canonical tool or clearly document the distinction (e.g., one lists recent events, the other performs deeper analysis).
Error handling and recovery guidance absent. No tool documents what errors it can return, what conditions cause them, or how the agent should respond. For example, sec_edgar_cik_lookup might fail if the company name is ambiguous or not found, the tool should return available candidates or actionable error guidance, not a bare 404.
Insufficient description length. Tools 'sec_edgar_analyze_8k' (25 chars) and 'sec_edgar_xbrl_parse' (30 chars) have descriptions under the 50-character minimum for LLM comprehension. These are too vague to drive reliable tool selection.
Parameter relationships undocumented. Tool sec_edgar_filing_search accepts 'cik' and 'ticker', are both required, mutually exclusive, or optional? Tool sec_edgar_financial_statements accepts 'form_type' and 'year', does the tool validate that 10-K is annual and 10-Q is quarterly? Undocumented dependencies cause silent misuse.