Skip to main content
Glama

AlphaCreek SEC Filings MCP

search_sec_event_filings

Read-only

Search US SEC 8-K and 6-K current-report nodes for company events and disclosures. Use this to discover issuers across a date range. Do not use this for 10-K or 10-Q filings. How to search:

  1. Always pass query with likely verbatim disclosure phrases. Each item is an exact adjacent-token phrase. Put alternate full phrasings in the same list. Do not put broad topic words such as "China", "AI", "customer", or "restructuring" alone in query.

  2. For open-ended discovery, also pass concept_groups. Every group is required (AND). Within each group's any_of list, one alternative must match (OR). All groups match inside one filing node. Use separate groups for the main context, action or direction, business object or metric, and a causal or limiting relation when that relation is essential.

  3. Add real synonyms and alternate filing language to any_of. The concept path uses English stemming, so one base form usually covers inflections (decline/declined/declining and volume/volumes). Stemming does not add synonyms (sales does not mean revenue; reduce does not mean weaken).

  4. Exact phrase matches receive a score boost. Concept groups are a fallback for different wording. If concept_groups is omitted, the search is exact-phrase only.

  5. Use date filters for time and tickers to search only selected issuers. Pass ne_tickers (or prefix a symbol with !) to omit issuers.

  6. Results are candidates, not final conclusions. Call read_node_content with each promising document_id and node_id(s). Verify negation, causal claims, comparisons across periods, and numeric thresholds such as a percentage or dollar amount in the source text. Cite CITATION_MARKDOWN. When you finish an issuer, search again with the same inputs and add its ticker to ne_tickers so later hits come from other issuers. Examples of useful group dimensions include geography + weakening signal + demand metric; CapEx + reduction + guidance; AI/automation + enablement + workforce + reduction; customer + loss/concentration; data centers + exposure + monetization; or restructuring + program/charge. Do not add a group for a detail that the filing may leave implicit, because every group is mandatory. Each result is one filing node: document_id, node_id, parent_node_id, ticker, type, filing_date, match_mode, query, score, and a short snippet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum unique matches to return across all query phrases. At most 3 matches come from one filing.
queryYesRequired exact disclosure phrases (max 8). Each phrase requires adjacent tokens in order and does not use stemming. Send complete event phrasings, not standalone topics. Examples: ["reduced capital expenditures", "lower capital spending"]; ["lost a major customer", "termination by our largest customer"]; ["workforce reduction", "reduce headcount"].
tickersNoOptional. Search only these issuers (example: ["NVDA", "MSFT"]). Prefix a symbol with ! to omit it (same as ne_tickers). Max 50. Omit to search all issuers.
end_dateYesInclusive end date on filing_date (YYYY-MM-DD)
ne_tickersNoOptional. Omit these issuers (example: ["HOOD"] or ["!HOOD"]). After you finish read_node_content for a ticker, search again with that ticker here. Exclude wins if a ticker is in both lists. Max 50.
start_dateYesInclusive start date on filing_date (YYYY-MM-DD)
concept_groupsNoOptional stemmed concept fallback for broad discovery. Every group must match in the same node (AND). Any one alternative inside any_of can satisfy its group (OR). Use 2-5 focused groups in most searches. Supply synonyms and alternate filing terms, but omit simple inflections because English stemming handles them. Do not use this field to prove numeric thresholds, negation, causality, or changes across several filings; retrieve candidates and verify those claims with read_node_content.

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/destructive annotations, it discloses exact adjacent-token phrase matching, stemming behavior, score boosts, concept-group fallback, candidate-only output, and a max of 3 matches per filing. This adds substantial behavioral context without contradicting the annotations.

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?

Long but structured and front-loaded: purpose first, then a numbered search procedure, then concrete examples. The detail is warranted for a complex query tool, though a small amount of duplication with schema descriptions exists.

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?

Even without an output schema, it enumerates exact result fields and explains that results are candidates requiring verification via read_node_content. It covers query construction, date/ticker filtering, exclusions, and follow-up searching, so nothing essential is missing.

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 complete, and the description adds high-value nuance: query phrases must be verbatim adjacent-token phrases, concept_groups are AND across groups and OR within any_of, steming does not add synonyms, broad topic words should not be used alone, and ticher/ne_ticker semantics are clarified.

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: 'Search US SEC 8-K and 6-K current-report nodes for company events and disclosures.' It also scopes the use case ('discover issuers across a date range') and explicitly excludes 10-K/10-Q, making it distinguishable from sibling filing-access tools.

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?

Provides explicit when-to-use and when-not-to-use guidance: 'Use this to discover issuers across a date range. Do not use this for 10-K or 10-Q filings.' It also directs follow-up verification to read_node_content and describes the iterative ne_tickers workflow.

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.

TDQS

A4.4/5.0
Disambiguation4/5

Each tool maps to a distinct step in the filing workflow—listing, latest metadata, TOC, node content, and event search—but get_latest_filing and list_filings both return filing metadata with similar fields, and get_filing_toc can also resolve the latest filing. The descriptions clarify the differences well, yet an agent could still hesitate between these overlapping entry points.

Naming Consistency5/5

All tool names follow a clear verb_noun pattern: get_filing_toc, get_latest_filing, list_filings, read_node_content, search_sec_event_filings. There is no mixed casing or vague verb usage, and each object noun is specific to its role.

Tool Count5/5

Five tools is a well-scoped count for a filing retrieval and search server. The set covers discovery, metadata access, TOC navigation, content reading, and targeted event search without redundant tools or obvious bloat.

Completeness4/5

The core lifecycle is covered: discover filings, get filing metadata, navigate the TOC, and read cited node content. Minor gaps exist, such as no full-text search over 10-K/10-Q filings and no direct metadata lookup by an arbitrary document_id, but these can be worked around using list_filings and read_node_content.

Resources