Skip to main content
Glama

Search Filing Text

search_filing_text
Read-only

Full-text search across SEC filing content that returns the matching passage: one match per filing, with the exhibit it was found in (exhibit_id, exhibit_type) and a snippet with context. Query syntax: unquoted words all have to appear (any order, any distance); "quoted phrase" = exact wording; OR between alternatives (merger OR acquisition); -word or -"phrase" to exclude; w1 NEAR/10 w2 (also NEAR(10), or bare NEAR = within 10) = words close together; word* = prefix of 4+ letters (dilut* matches dilution, dilutive); $AAPL or a capitalised ticker scopes to that company; a form code (8-K, 10-Q, S-1), "item 5.02" / "8-K 1.05" and a bare year (2024) scope to that form / 8-K item / year. Quoted multi-word phrases match as phrases; the archive's reading of the query is in meta.understanding. Suited to locating specific clauses ("change of control", "anti-dilution", "right of first refusal") and to the excerpt of a known filing (accessionNumber or filingId). It has no filing-level paging, totals, date ranges, 8-K item, excluded-form or company filters. Filters: CIK, filing, accession number, form type, section (risk_factors, mdna, ex99 …; applied only when meta.sections confirms it, otherwise meta.unsupported says the whole filing was searched) and exhibitTypes (EX-10 …). Coverage: Signal8's SEC EDGAR archive, updated through the day, in its held range (see archiveFrom in each response; currently from late 2021, expanding back to 2016 as the history backfill fills in). Before archiveFrom it holds only a scatter, so absence before archiveFrom is not evidence a filing was never filed; SEC EDGAR itself covers earlier periods. Record-only rows (bodyStored: false) have no stored body; the document is at its sec.gov URL.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pattern": "<pattern>"
    },
    "name": "search_filing_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
cikNoFilter to a specific company by CIK number
sortNoResult order: newest (default) or relevance (best match first)
limitNoMax results (default: 20, max: 100)
matchNoWord matching. exact = a word matches only itself ("split" does not match "splits"), which is EDGAR full-text search's behaviour; stemmed = English word variations also match. Default when omitted: stemmed. The mode actually applied is reported in the response's meta.matchMode.
facetsNotrue = also return `facets` { forms, years, items }: [{ value, count }] over the whole match set. Absent when not measured (not zero). Default false.
patternYesSearch query (minimum 2 characters): "exact phrase", OR, -exclude, w1 NEAR/n w2, word*, $TICKER. A CIK/filing-scoped search whose text is not indexed yet falls back to a literal case-insensitive substring match (response engine: "substring"); there each "quoted phrase" and bare word must appear (quotes stripped), and meta.substringTerms lists the terms matched. OR, NEAR, -exclude and word* are not applied on that path.
sectionNoRestricts matching to sections (comma-separated): business, risk_factors, cybersecurity, legal_proceedings, mdna, market_risk, controls (10-K/10-Q/20-F narrative items, by meaning: mdna is 10-K Item 7, 10-Q Part I Item 2 and 20-F Item 5), ex99 (press-release / EX-99.x exhibit text) and item_X_YY (the text under an 8-K item, e.g. item_5_02). Aliases: mda, risk, legal, cyber, press_release, 5.02. Unknown names are a 400. Requires q. Applied only when the response's meta.sections names it; otherwise meta.unsupported says why (e.g. the archive index does not have sections yet) and matches may come from anywhere in the filing.
filingIdNoFilter to a specific filing by internal ID
formTypeNoFilter by form type (e.g., "10-K", "S-1")
understandNoQuery understanding (default true): tickers/$TICKER, company names, form codes, "item N.NN" and synonym expansion, reported in meta.understanding. false = match the words literally.
exhibitTypesNoKeeps only filings carrying any of these exhibit types (comma-separated): a family such as EX-10 (material contracts) matches every member (EX-10.1, EX-10.2…); an exact type such as EX-99.1 (usually the press release) only itself. Others: EX-97 clawback policy, EX-3 charter/bylaws, EX-4 instruments/warrants, EX-21 subsidiaries, EX-23 consents. "10.1" is accepted for EX-10.1. Listed in appliedFilters when the rows prove it; otherwise in ignoredFilters / meta.unsupported, and the rows are then unfiltered.
snippetLengthNoCharacters of context around each match (default: 200)
accessionNumberNoFilter to a specific filing by SEC accession number
matchedSectionsNoPer-row `matchedSections` (default true): the sections the text matched in. Absent on a row means not measured (index without sections), not "matched nowhere".

Output Schema

NameRequiredDescriptionDefault
dataNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / exhibitTypes / description
      Previous value: -"Keep only filings carrying ANY of these exhibit types (comma-separated): a family such as EX-10 (material contracts) matches every member (EX-10.1, EX-10.2…); an exact type such as EX-99.1 (usually the press release) only itself. Others: EX-97 clawback policy, EX-3 charter/bylaws, EX-4 instruments/warrants, EX-21 subsidiaries, EX-23 consents. \"10.1\" is accepted for EX-10.1. Listed in appliedFilters when the rows prove it; otherwise in ignoredFilters / meta.unsupported — treat the rows as unfiltered then."New value: +"Keeps only filings carrying any of these exhibit types (comma-separated): a family such as EX-10 (material contracts) matches every member (EX-10.1, EX-10.2…); an exact type such as EX-99.1 (usually the press release) only itself. Others: EX-97 clawback policy, EX-3 charter/bylaws, EX-4 instruments/warrants, EX-21 subsidiaries, EX-23 consents. \"10.1\" is accepted for EX-10.1. Listed in appliedFilters when the rows prove it; otherwise in ignoredFilters / meta.unsupported, and the rows are then unfiltered."
    • changedInput schema / properties / facets / description
      Previous value: -"true = also return `facets` { forms, years, items } — [{ value, count }] over the whole match set. Absent when not measured (never zero). Default false."New value: +"true = also return `facets` { forms, years, items }: [{ value, count }] over the whole match set. Absent when not measured (not zero). Default false."
    • changedInput schema / properties / match / description
      Previous value: -"Word matching. exact = a word matches only itself (\"split\" does NOT match \"splits\") — EDGAR full-text search's behaviour; stemmed = English word variations also match. Default when omitted: stemmed. The mode actually applied is reported in the response's meta.matchMode."New value: +"Word matching. exact = a word matches only itself (\"split\" does not match \"splits\"), which is EDGAR full-text search's behaviour; stemmed = English word variations also match. Default when omitted: stemmed. The mode actually applied is reported in the response's meta.matchMode."
    • changedInput schema / properties / matchedSections / description
      Previous value: -"Per-row `matchedSections` (default true): the sections the text matched in. ABSENT on a row means not measured (index without sections), never \"matched nowhere\"."New value: +"Per-row `matchedSections` (default true): the sections the text matched in. Absent on a row means not measured (index without sections), not \"matched nowhere\"."
    • changedInput schema / properties / section / description
      Previous value: -"Restrict MATCHING to sections (comma-separated): business, risk_factors, cybersecurity, legal_proceedings, mdna, market_risk, controls (10-K/10-Q/20-F narrative items, by meaning — mdna is 10-K Item 7, 10-Q Part I Item 2 and 20-F Item 5), ex99 (press-release / EX-99.x exhibit text) and item_X_YY (the text under an 8-K item, e.g. item_5_02). Aliases: mda, risk, legal, cyber, press_release, 5.02. Unknown names are a 400. Needs q. Applied ONLY when the response's meta.sections names it — otherwise meta.unsupported says why (e.g. the archive index does not have sections yet) and matches may come from ANYWHERE in the filing."New value: +"Restricts matching to sections (comma-separated): business, risk_factors, cybersecurity, legal_proceedings, mdna, market_risk, controls (10-K/10-Q/20-F narrative items, by meaning: mdna is 10-K Item 7, 10-Q Part I Item 2 and 20-F Item 5), ex99 (press-release / EX-99.x exhibit text) and item_X_YY (the text under an 8-K item, e.g. item_5_02). Aliases: mda, risk, legal, cyber, press_release, 5.02. Unknown names are a 400. Requires q. Applied only when the response's meta.sections names it; otherwise meta.unsupported says why (e.g. the archive index does not have sections yet) and matches may come from anywhere in the filing."
  2. Changed1 schema field changed
    • changedInput schema / properties / pattern / description
      Previous value: -"Search query (minimum 2 characters): \"exact phrase\", OR, -exclude, w1 NEAR/n w2, word*, $TICKER. A CIK/filing-scoped search whose text is not indexed yet falls back to a literal case-insensitive substring match (response engine: \"substring\")."New value: +"Search query (minimum 2 characters): \"exact phrase\", OR, -exclude, w1 NEAR/n w2, word*, $TICKER. A CIK/filing-scoped search whose text is not indexed yet falls back to a literal case-insensitive substring match (response engine: \"substring\"); there each \"quoted phrase\" and bare word must appear (quotes stripped), and meta.substringTerms lists the terms matched. OR, NEAR, -exclude and word* are not applied on that path."
  3. Changed6 schema fields changed
    • addedInput schema / properties / exhibitTypes
      Added value: +{
      +  "description": "Keep only filings carrying ANY of these exhibit types (comma-separated): a family such as EX-10 (material contracts) matches every member (EX-10.1, EX-10.2…); an exact type such as EX-99.1 (usually the press release) only itself. Others: EX-97 clawback policy, EX-3 charter/bylaws, EX-4 instruments/warrants, EX-21 subsidiaries, EX-23 consents. \"10.1\" is accepted for EX-10.1. Listed in appliedFilters when the rows prove it; otherwise in ignoredFilters / meta.unsupported — treat the rows as unfiltered then.",
      +  "maxLength": 400,
      +  "type": "string"
      +}
    • addedInput schema / properties / facets
      Added value: +{
      +  "description": "true = also return `facets` { forms, years, items } — [{ value, count }] over the whole match set. Absent when not measured (never zero). Default false.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / matchedSections
      Added value: +{
      +  "description": "Per-row `matchedSections` (default true): the sections the text matched in. ABSENT on a row means not measured (index without sections), never \"matched nowhere\".",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / pattern / description
      Previous value: -"Search query (minimum 2 characters), websearch syntax: \"exact phrase\", OR, -exclude. A CIK/filing-scoped search whose text is not indexed yet falls back to a literal case-insensitive substring match (response engine: \"substring\")."New value: +"Search query (minimum 2 characters): \"exact phrase\", OR, -exclude, w1 NEAR/n w2, word*, $TICKER. A CIK/filing-scoped search whose text is not indexed yet falls back to a literal case-insensitive substring match (response engine: \"substring\")."
    • addedInput schema / properties / section
      Added value: +{
      +  "description": "Restrict MATCHING to sections (comma-separated): business, risk_factors, cybersecurity, legal_proceedings, mdna, market_risk, controls (10-K/10-Q/20-F narrative items, by meaning — mdna is 10-K Item 7, 10-Q Part I Item 2 and 20-F Item 5), ex99 (press-release / EX-99.x exhibit text) and item_X_YY (the text under an 8-K item, e.g. item_5_02). Aliases: mda, risk, legal, cyber, press_release, 5.02. Unknown names are a 400. Needs q. Applied ONLY when the response's meta.sections names it — otherwise meta.unsupported says why (e.g. the archive index does not have sections yet) and matches may come from ANYWHERE in the filing.",
      +  "maxLength": 400,
      +  "type": "string"
      +}
    • addedInput schema / properties / understand
      Added value: +{
      +  "description": "Query understanding (default true): tickers/$TICKER, company names, form codes, \"item N.NN\" and synonym expansion, reported in meta.understanding. false = match the words literally.",
      +  "type": "boolean"
      +}
  4. Changed2 schema fields changed
    • addedInput schema / properties / match
      Added value: +{
      +  "description": "Word matching. exact = a word matches only itself (\"split\" does NOT match \"splits\") — EDGAR full-text search's behaviour; stemmed = English word variations also match. Default when omitted: stemmed. The mode actually applied is reported in the response's meta.matchMode.",
      +  "enum": [
      +    "exact",
      +    "stemmed"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / sort
      Added value: +{
      +  "description": "Result order: newest (default) or relevance (best match first)",
      +  "enum": [
      +    "newest",
      +    "relevance"
      +  ],
      +  "type": "string"
      +}
  5. Changed1 schema field changed
    • changedInput schema / properties / pattern / description
      Previous value: -"Search pattern (minimum 2 characters). Substring match, case-insensitive."New value: +"Search query (minimum 2 characters), websearch syntax: \"exact phrase\", OR, -exclude. A CIK/filing-scoped search whose text is not indexed yet falls back to a literal case-insensitive substring match (response engine: \"substring\")."
  6. Changed9 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / accessionNumber / description
      Added value: +"Filter to a specific filing by SEC accession number"
    • addedInput schema / properties / cik / description
      Added value: +"Filter to a specific company by CIK number"
    • addedInput schema / properties / filingId / description
      Added value: +"Filter to a specific filing by internal ID"
    • addedInput schema / properties / formType / description
      Added value: +"Filter by form type (e.g., \"10-K\", \"S-1\")"
    • addedInput schema / properties / limit / description
      Added value: +"Max results (default: 20, max: 100)"
    • addedInput schema / properties / pattern / description
      Added value: +"Search pattern (minimum 2 characters). Substring match, case-insensitive."
    • addedInput schema / properties / snippetLength / description
      Added value: +"Characters of context around each match (default: 200)"
    • removedOutput schema / required
      Removed value: -[
      -  "data"
      -]
  7. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "data": {}
      +  },
      +  "required": [
      +    "data"
      +  ],
      +  "type": "object"
      +}
  8. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond readOnly/non-destructive annotations, it discloses that a CIK/filing-scoped search falls back to literal substring matching with a different grammar, that section and exhibitType filters are only honoured when meta confirms them (otherwise rows are unfiltered), that record-only rows (bodyStored: false) have no stored body, and that absence before archiveFrom is not evidence a filing was never filed. Those are exactly the non-obvious behaviours that would otherwise cause an agent to draw false conclusions.

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?

Purpose, return shape, query syntax, exclusions, filters and coverage are front-loaded in a sensible order, and the length is largely earned by a 14-parameter tool with a bespoke query language. There is some duplication of output-schema territory (meta.understanding, meta.sections, meta.unsupported, appliedFilters/ignoredFilters explained in more than one place), which keeps it from 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?

An output schema exists, so return values need not be spelled out, yet the description still supplies the two things structured fields cannot: archive coverage bounds (currently late 2021, backfilling to 2016) and the fallback/filter-honouring caveats that determine when an empty or unfiltered result is meaningful. For a search tool of this complexity, an agent has everything needed to query and interpret results correctly.

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 100%, so the baseline is 3, but the description adds substantial meaning the schema does not carry: the full query grammar (unquoted AND, quoted phrases, OR, -exclusion, NEAR/10, 4+ letter prefix wildcards, $TICKER, form codes, 8-K items, bare years), the section aliases and the fact that unknown names produce a 400, and exhibit-type family versus exact-type semantics (EX-10 vs EX-99.1, '10.1' accepted).

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?

Opens with a specific verb and resource: full-text search over SEC filing content returning the matching passage plus exhibit_id/exhibit_type and a snippet. It then explicitly delimits itself against the sibling family by stating it has 'no filing-level paging, totals, date ranges, 8-K item, excluded-form or company filters', which separates it from search_sec_filings and get_filing_document without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use cases: locating specific clauses ('change of control', 'anti-dilution') and pulling the excerpt from a known filing via accessionNumber or filingId. It also states what the tool cannot do, which implicitly routes agents elsewhere. It never names the alternative sibling tools (search_sec_filings, get_filing_document) that an agent should pick for filing-level or document retrieval, so it stops short of explicit alternatives.

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.