Skip to main content
Glama

MetricDuck — Financial Analysis

Recent Filings Feed

list_recent_filings
Read-only

Use this when the user asks what SEC filings came out recently — "any new 10-Ks, 10-Qs or 8-Ks this week?", "which of my portfolio companies filed since Monday?", "who reported earnings today?" — across all companies or a list of tickers, in one call. Also the building block for alerts and daily portfolio checks.

Returns: a flat list of {ticker, accession, filed_at, form_type, form_subtype}, newest filing date first and largest companies first within a date — so limit=15 during earnings week surfaces the banks and mega-caps that filed, not alphabetically-first micro-caps. form_subtype classifies 8-Ks (values under form_subtypes); null for other forms.

Portfolio filter: tickers (an array); ticker="TSM" is accepted as an alias. Both given = union, cap 50. One call covers the portfolio — no per-ticker list_filings fan-out.

Read a row's filing with get_filing_section(ticker, accession_number=...) — omit section_id for its section outline. For every filing of ONE company, use list_filings.

Not point-in-time: the live feed as of today (one company as of a past date: list_filings with vantage_date).

Input Schema

NameRequiredDescriptionDefault
limitNoMax results (default 50, max 100). Sorted newest filing date first, then by company size, so a small limit still surfaces the largest issuers that filed.
sinceNoFiling date floor (inclusive): the SEC filing date, not the date MetricDuck extracted it. YYYY-MM-DD; omit for the last 30 days. A small share of filings (mostly 8-K and 6-K exhibits) are extracted days or weeks after their filing date, so a poll from your last poll's date misses them: look back up to a month and dedupe by accession.
tickerNoSingle-ticker alias of `tickers`. Both may be given (union, cap 50).
tickersNoOptional portfolio filter. Up to 50 tickers. Omit to scan the full universe.
form_typesNoFilter by SEC form type. Examples: ['8-K'], ['8-K', '10-Q'], ['10-K']. Omit to include all form types.
form_subtypesNoFilter by 8-K sub-type derived from section inventory. '8-K-earnings' = earnings release; '8-K-transcript' = earnings call transcript; '8-K-event' = M&A / executive changes / debt; '8-K-other' = misc. Implies 8-K filings only. Omit to include all subtypes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / since / description
      Previous value: -"Filing date floor (inclusive): the SEC filing date, not the date MetricDuck extracted it. YYYY-MM-DD. Required. A small share of filings (mostly 8-K and 6-K exhibits) are extracted days or weeks after their filing date, so a poll from your last poll's date misses them: look back up to a month and dedupe by accession."New value: +"Filing date floor (inclusive): the SEC filing date, not the date MetricDuck extracted it. YYYY-MM-DD; omit for the last 30 days. A small share of filings (mostly 8-K and 6-K exhibits) are extracted days or weeks after their filing date, so a poll from your last poll's date misses them: look back up to a month and dedupe by accession."
    • removedInput schema / required
      Removed value: -[
      -  "since"
      -]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), and the description adds substantial behavior beyond them: the exact return shape, the newest-date-then-largest-company sort that makes small `limit` values meaningful, the alias/union semantics with a cap of 50, and the polling caveat about late-extracted filings needing lookback and dedupe.

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 usage scenarios and cleanly sectioned with bold Returns/Portfolio filters headers, so an agent can skim. It is somewhat long and repeats a fair amount of what the schema already says, which keeps it short of a 5.

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 fully compensates by specifying the returned fields, ordering, and the form_subtype classification. Combined with the routing guidance to get_filing_section and list_filings, an agent has everything needed to call and consume this tool correctly.

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 baseline is 3 and the heavy lifting is already done in the schema. The description largely restates that content (ticker alias, union cap 50, limit/sort, since floor) rather than adding new parameter meaning, earning no bump above baseline.

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?

States a specific verb and resource ('SEC filings came out recently') and gives concrete user-facing phrasings that pin down the intent. It explicitly separates itself from siblings ('For every filing of ONE company, use list_filings'), so an agent can route without opening either schema.

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?

Explicit when-to-use (recent filings across the universe or a portfolio list, alerts, daily checks) and when-NOT (not point-in-time; single-company historical = list_filings with vantage_date; full-company listing = list_filings). It also warns against per-ticker fan-out, which directly shapes invocation strategy.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources