Skip to main content
Glama

KeyVex

get_material_events

Read-only

Returns Form 8-K filings — the SEC's 'current report' form, filed within 4 business days of any material event at a publicly-traded company. Each record is one filing, with item_codes declaring WHAT kind of event(s) it covers. Use this when the user asks about: recent CEO/CFO departures or appointments, M&A announcements, earnings releases, big contract wins, restructurings, going-concern warnings, exec compensation changes, or any 'what just happened at this company' question. Item codes (most-used; many more exist): 1.01 Entry into a Material Definitive Agreement 1.02 Termination of a Material Definitive Agreement 2.01 Completion of Acquisition or Disposition of Assets 2.02 Results of Operations (earnings releases live here) 2.03 Creation of a Material Direct Financial Obligation 3.01 Notice of Delisting / Failure to Satisfy Listing Rule 3.02 Unregistered Sales of Equity Securities 4.01 Changes in Registrant's Certifying Accountant 5.02 Departure / Election / Appointment of Officers + Directors 5.07 Submission of Matters to a Vote of Security Holders 7.01 Regulation FD Disclosure 8.01 Other Events (catch-all) 9.01 Financial Statements and Exhibits — NOTE: nearly every 8-K ticks this 'paperwork box.' Searching JUST for 9.01 returns the firehose; combine it with another item_code to focus. item_codes filter is OR-semantic: pass an array, match any filing containing AT LEAST ONE of those codes. Capped at 30 codes per query (Firestore array-contains-any limit). Examples: ['5.02'] for exec changes; ['1.01','2.01'] for any deal activity (LOI or close); ['2.02'] for earnings. Amendments (8-K/A) get their own row with is_amendment: true. The original 8-K stays in place. v1 does NOT populate original_accession_number; agents can find candidates by matching (ticker, period_of_report) across rows. Filter is_amendment: false for clean original-only views. v1 does not extract the prose body — primary_document_url points agents at the source HTML for direct fetch. The structured items are what's queryable here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum records to return. Default 50, max 500.
sinceNoISO date (YYYY-MM-DD). Only records on or after this date, using sort_by as the date field.
untilNoISO date (YYYY-MM-DD). Only records on or before this date.
tickerNoStock symbol filter, e.g. 'AAPL'. Case-insensitive.
sort_byNoField used for ordering and for since/until filters. filing_date = when filed with SEC; period_of_report = when the underlying event occurred. Default: filing_date. NOTE: a small number of 8-Ks (Reg-FD-only filings, item-7.01 disclosures) lack period_of_report at the SEC source — those rows fall back to filing_date ordering automatically, so sort_by='period_of_report' won't bury them.
item_codesNoArray of item codes to filter on (OR semantics). E.g., ['5.02'] for exec changes, ['1.01','2.01'] for any deal activity. Max 30 codes per query.
sort_orderNoDefault: desc (most recent first).
company_cikNoSEC CIK number (10-digit, padded with leading zeros). Alternative to ticker.
is_amendmentNoFilter to only original 8-Ks (false) or only amendments / 8-K/A filings (true). Omit to include both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description layers on non-obvious behavior: OR-semantics and the 30-code Firestore cap, how 8-K/A amendments are stored as separate rows with is_amendment, that v1 leaves original_accession_number unpopulated, and that v1 does not extract the prose body so primary_document_url must be fetched. This is rich context beyond the structured fields.

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 definition before the usage triggers, and every block (item codes, amendment handling, v1 limitations) carries information. The item-code glossary is long but justified; there is minor redundancy with the schema's item_codes example text.

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?

With no output schema, the description compensates by describing the record shape, the item_codes field, the amendment row model, and the primary_document_url escape hatch for prose. An agent has everything needed to query and to explain results to a user.

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 the baseline is 3, but the description adds real value: a glossary mapping item codes to event meanings that is absent from the schema, plus the explicit 30-code cap and OR semantics that shape how item_codes should be constructed. It stops short of full syntax depth for the date/sort parameters, which the schema already handles.

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 resource (SEC Form 8-K current reports), defines it inline ('filed within 4 business days of any material event'), and explains the record granularity ('Each record is one filing, with item_codes declaring WHAT kind of event(s)'). An agent can distinguish this from sibling filing tools like get_insider_filings or get_proxy_filings purely from the text.

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 enumerates the trigger questions ('recent CEO/CFO departures or appointments, M&A announcements, earnings releases...') and gives concrete item_code recipes for each use case (['5.02'], ['1.01','2.01'], ['2.02']). It also warns against a specific misuse — searching only 9.01 returns the firehose.

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