Skip to main content
Glama

Recent Filings

sec_recent_filings
Read-only

Retrieve recent SEC filings for a company by ticker or recent EDGAR-wide filings, with optional form type filtering.

Instructions

Get recent SEC filings (10-K, 10-Q, 8-K, etc.) for a company by ticker symbol, or, with no ticker, the latest filings across all of EDGAR. For a company: returns the most recent filings first; when a form_type filter is given, older history is paged in automatically if recent filings don't satisfy the requested limit. With no ticker: reads EDGAR's real-time latest-filings feed, which reaches back about two business days, newest first, filtered by form_type ('8-K', 'SCHEDULE 13D', '4'; amendments match too). Each row is one filing with its acceptance time, its parties (a Form 4's reporting person and issuer, a 13D's filers and subject company, each with CIK and role), an 8-K's items, and the filing's index URL for sec_filing_text. Pass 'next_offset' back as 'offset' for older pages. For filings by form further back than the feed reaches, use sec_full_text_search with 'forms' and a date range and no query.

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of filings to return (default 10, max 40)
offsetNoLatest filings across EDGAR only (no 'ticker'): the 'next_offset' from the previous page, to page further back.
tickerNoStock ticker, e.g. AAPL, or the company's CIK, e.g. 1163302, for one with no current ticker (delisted, acquired or renamed). Omit for the latest filings across all of EDGAR.
form_typeNoOptional filter: '10-K', '10-Q', '8-K', etc.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.10.0
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Latest filings across EDGAR only (no 'ticker'): the 'next_offset' from\nthe previous page, to page further back.",
      +  "format": "uint64",
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • changedInput schema / properties / ticker / description
      Previous value: -"Stock ticker, e.g. AAPL, or the company's CIK, e.g. 1163302, for one with no\ncurrent ticker (delisted, acquired or renamed)"New value: +"Stock ticker, e.g. AAPL, or the company's CIK, e.g. 1163302, for one with no\ncurrent ticker (delisted, acquired or renamed). Omit for the latest\nfilings across all of EDGAR."
    • removedInput schema / required
      Removed value: -[
      -  "ticker"
      -]
  2. Changed1 schema field changedv0.7.0
    • changedInput schema / properties / ticker / description
      Previous value: -"Stock ticker symbol"New value: +"Stock ticker, e.g. AAPL, or the company's CIK, e.g. 1163302, for one with no\ncurrent ticker (delisted, acquired or renamed)"
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld; the description adds real behavioral context: the no-ticker feed reaches back roughly two business days, results are newest-first, amendments match form_type filters, and older history is paged in automatically when a form_type is set. It also describes row shape (acceptance time, parties with CIK and role, 8-K items, index URL) and the next_offset paging contract.

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?

Front-loaded with the core purpose and mode split, and the mode-specific details follow in order. It is a dense, fairly long paragraph with a heavy row-structure clause, but with no output schema that detail is load-bearing rather than padding.

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

Completeness5/5

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

No output schema exists, and the description compensates by describing the returned row fields and the paging field. Combined with the mode split, feed time horizon, and escape hatch to sec_full_text_search, an agent has everything needed to call this correctly on the first try.

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 still adds meaning by tying form_type to the auto-paging behavior and amendment matching, and clarifying that offset applies only to the no-ticker feed. It does not restate limit bounds or the CIK-vs-ticker fallback, which the schema already covers.

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?

Specific verb and resource ("Get recent SEC filings") with the form types enumerated and two clearly separated modes: ticker-scoped company filings vs. the all-EDGAR latest feed. It also distinguishes itself from siblings by naming sec_filing_text (for the index URL) and sec_full_text_search (for older history).

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 states when each mode applies (ticker vs. omit ticker), when the form_type filter triggers automatic back-paging, and names the exact alternative for the out-of-scope case: "For filings by form further back than the feed reaches, use sec_full_text_search with 'forms' and a date range and no query." That is a complete routing instruction.

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