Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant

edgar_full_text_search

Read-only

Perform full-text search across SEC EDGAR filings from 2001 to present. Filter by form type, date range, CIK (exact entity match), or entity name (fuzzy) to narrow results.

Instructions

Full-text search across EDGAR filings, 2001-present (keyless, efts.sec.gov). Input q (phrase in double-quotes for exact), optional forms, startdt/enddt (ISO), ciks (pin filings BY entities — numeric 10-digit SEC CIKs, zero-padded, exact-entity match), entityName (FUZZY filer-name narrowing — can match related filers, e.g. multiple 'Apple*'), from (offset; page size FIXED at 100 — no size param). Returns { accession, form, filingDate, entityNames, ciks, filingIndexUrl }. HONESTY: totalAvailable = the true match count, or a LOWER BOUND (totalIsLowerBound:true) when SEC reports ≥10000; a 0-result set with ciks/entityName applied is NOT proof of absence (verify the CIK via edgar_lookup_cik by name/ticker); from > 9900 is rejected (10000-result window). NOTE: EDGAR keys on CIK, NOT SAM UEI/DUNS.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesFull-text query over EDGAR filings (2001-present). Wrap a phrase in double quotes for an exact match (e.g. '"climate risk"').
ciksNoOptional: pin filings BY one or more entities, by NUMERIC SEC CIK (each is zero-padded to 10 digits — an EXACT-entity match). Multiple CIKs are AND-of-OR (any of the listed entities). A ticker/company name / CIK-0 entry is rejected as invalid_input — use `entityName` or resolve the CIK first with edgar_lookup_cik.
fromNo0-based result offset for pagination; page size is FIXED at 100 (there is no size param). Must be <= 9900 (from+100 ≤ 10000 upstream window); a larger from is rejected as invalid_input.
enddtNoOptional ISO YYYY-MM-DD filing-date upper bound (sets dateRange=custom).
formsNoOptional form-type filter (e.g. ['10-K','8-K']).
startdtNoOptional ISO YYYY-MM-DD filing-date lower bound (sets dateRange=custom).
entityNameNoOptional FUZZY filer-name narrowing (matches the filer's display name; NOT CIK-exact — can match related entities, e.g. multiple 'Apple*' filers). Combine with `ciks` for an exact-entity result.
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint. Description goes beyond: reveals totalAvailable may be lower bound, 10000-result window, from rejection, and that 0 results with ciks/entityName require verification. Provides HONESTY note about SEC reporting limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: front-loads core purpose, then lists parameters in order with clear syntax notes, followed by key behavioral notes. Every sentence adds value; no fluff. Efficiently packs parameter semantics and warnings without redundancy.

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?

For a complex 7-parameter tool without output schema, the description is complete. It covers all parameters, pagination, result fields, behavioral quirks, and cross-references another tool (edgar_lookup_cik). Even notes key difference (CIK not SAM UEI/DUNS). Leaves no gaps for correct invocation.

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?

Even though schema coverage is 100%, the description adds significant value: explains q exact-match syntax, ciks format and validation, from pagination limits, entityName fuzzy matching, and suggests combining ciks with entityName. Each parameter is enriched with non-obvious usage details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Full-text search across EDGAR filings, 2001-present' with specific verb and resource. While the purpose is obvious, it does not explicitly differentiate from sibling tools like edgar_company_filings or edgar_filing_index, leaving the agent to infer when to use this vs others.

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?

Excellent guidance: explains when to use (full-text search with optional filters), how to use parameters (ciks vs entityName, from limits), and caveats (0 results not proof of absence, verify CIK via edgar_lookup_cik). Explicitly states page size is fixed at 100 and from > 9900 rejected.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cliwant/mcp-sam-gov'

If you have feedback or need assistance with the MCP directory API, please join our Discord server