Skip to main content
Glama

Search SEC Filings

search_sec_filings

Search SEC EDGAR filings by CIK, form type, company name, and date range. Retrieve filing metadata including accession number, filing date, and document URLs.

Instructions

Search SEC EDGAR filings by CIK number, form type (10-K, 10-Q, 8-K, etc.), company name, and date range. Returns filing metadata including accession number, filing date, and document URLs. Source: SEC EDGAR, updated every 15 minutes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikNoCentral Index Key — SEC's unique company identifier (e.g. 0001652044 for Alphabet)
form_typeNoSEC form type (e.g. 10-K, 10-Q, 8-K, S-1, DEF 14A). Case-insensitive.
company_nameNoCompany name to search for (partial match)
date_fromNoStart date for filing date range (YYYY-MM-DD)
date_toNoEnd date for filing date range (YYYY-MM-DD)
limitNoMaximum number of results (default 25, max 100)

Implementation Reference

  • The async handler function for search_sec_filings. It calls apiGet to /api/v1/sec/filings with optional parameters (cik, form_type, company_name, date_from, date_to, limit), returns results as formatted text, or an error message on failure.
    async ({ cik, form_type, company_name, date_from, date_to, limit }) => {
      const res = await apiGet<SecFilingsResponse>("/api/v1/sec/filings", {
        cik,
        form_type,
        company_name,
        date_from,
        date_to,
        limit: limit ?? 25,
      });
    
      if (!res.ok) {
        return {
          content: [
            {
              type: "text" as const,
              text: `API error (${res.status}): ${JSON.stringify(res.data)}`,
            },
          ],
          isError: true,
        };
      }
    
      const { count, data } = res.data;
      const summary = `Found ${count} SEC filing(s).`;
      const json = JSON.stringify(data, null, 2);
    
      return {
        content: [{ type: "text" as const, text: `${summary}\n\n${json}` }],
      };
    },
  • Input schema for search_sec_filings using Zod: optional cik (string), form_type (string), company_name (string), date_from (string YYYY-MM-DD), date_to (string YYYY-MM-DD), and limit (number 1-100).
    inputSchema: {
      cik: z
        .string()
        .optional()
        .describe(
          "Central Index Key — SEC's unique company identifier (e.g. 0001652044 for Alphabet)",
        ),
      form_type: z
        .string()
        .optional()
        .describe(
          "SEC form type (e.g. 10-K, 10-Q, 8-K, S-1, DEF 14A). Case-insensitive.",
        ),
      company_name: z
        .string()
        .optional()
        .describe("Company name to search for (partial match)"),
      date_from: z
        .string()
        .optional()
        .describe("Start date for filing date range (YYYY-MM-DD)"),
      date_to: z
        .string()
        .optional()
        .describe("End date for filing date range (YYYY-MM-DD)"),
      limit: z
        .number()
        .int()
        .min(1)
        .max(100)
        .optional()
        .describe("Maximum number of results (default 25, max 100)"),
    },
  • Registration of the 'search_sec_filings' tool via server.registerTool() with title, description, inputSchema, and the async handler callback.
    server.registerTool(
      "search_sec_filings",
      {
        title: "Search SEC Filings",
        description:
          "Search SEC EDGAR filings by CIK number, form type (10-K, 10-Q, 8-K, etc.), " +
          "company name, and date range. Returns filing metadata including accession number, " +
          "filing date, and document URLs. Source: SEC EDGAR, updated every 15 minutes.",
        inputSchema: {
          cik: z
            .string()
            .optional()
            .describe(
              "Central Index Key — SEC's unique company identifier (e.g. 0001652044 for Alphabet)",
            ),
          form_type: z
            .string()
            .optional()
            .describe(
              "SEC form type (e.g. 10-K, 10-Q, 8-K, S-1, DEF 14A). Case-insensitive.",
            ),
          company_name: z
            .string()
            .optional()
            .describe("Company name to search for (partial match)"),
          date_from: z
            .string()
            .optional()
            .describe("Start date for filing date range (YYYY-MM-DD)"),
          date_to: z
            .string()
            .optional()
            .describe("End date for filing date range (YYYY-MM-DD)"),
          limit: z
            .number()
            .int()
            .min(1)
            .max(100)
            .optional()
            .describe("Maximum number of results (default 25, max 100)"),
        },
      },
      async ({ cik, form_type, company_name, date_from, date_to, limit }) => {
        const res = await apiGet<SecFilingsResponse>("/api/v1/sec/filings", {
          cik,
          form_type,
          company_name,
          date_from,
          date_to,
          limit: limit ?? 25,
        });
    
        if (!res.ok) {
          return {
            content: [
              {
                type: "text" as const,
                text: `API error (${res.status}): ${JSON.stringify(res.data)}`,
              },
            ],
            isError: true,
          };
        }
    
        const { count, data } = res.data;
        const summary = `Found ${count} SEC filing(s).`;
        const json = JSON.stringify(data, null, 2);
    
        return {
          content: [{ type: "text" as const, text: `${summary}\n\n${json}` }],
        };
      },
    );
  • src/index.ts:40-40 (registration)
    Top-level registration call: registerSecTools(server) in the main server setup, which registers all SEC tools including search_sec_filings.
    registerSecTools(server);
  • The apiGet helper function used by the handler to make HTTP GET requests to the Verilex API. It builds the URL, sends the request, and returns parsed JSON with status metadata.
    export async function apiGet<T = unknown>(
      path: string,
      params?: Record<string, string | number | undefined>,
    ): Promise<ApiResponse<T>> {
      const url = buildUrl(path, params);
    
      const headers: Record<string, string> = {
        Accept: "application/json",
        "User-Agent": "verilex-mcp-server/0.1.0",
      };
    
      // Forward x402 payment token if present in env (for paid endpoints)
      const paymentToken = process.env.VERILEX_PAYMENT_TOKEN;
      if (paymentToken) {
        headers["X-Payment-Token"] = paymentToken;
      }
    
      const res = await fetch(url, { headers });
      const data = (await res.json()) as T;
    
      const stale = res.headers.get("X-Data-Stale");
      const lastUpdated = res.headers.get("X-Data-Last-Updated");
      const ageSeconds = res.headers.get("X-Data-Age-Seconds");
    
      return {
        ok: res.ok,
        status: res.status,
        data,
        stale: stale === "true",
        lastUpdated: lastUpdated ?? undefined,
        ageSeconds: ageSeconds ? Number(ageSeconds) : undefined,
      };
    }
Behavior4/5

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

Discloses source (SEC EDGAR), update frequency (every 15 minutes), and return type (metadata). No annotations provided, but description covers essential behavioral traits for a read-only search tool.

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?

Two concise sentences: first states parameters and action, second states returns and source. No wasted words; front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and no annotations, the description covers the search purpose, input fields, and return format adequately. Lacks explanation of edge cases or error handling, but sufficient for a straightforward search tool.

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 has 100% description coverage for all 6 parameters. Description mentions parameters in narrative but does not add significant meaning beyond what schema provides. Baseline score of 3 applies.

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?

Description clearly states the tool searches SEC EDGAR filings by CIK, form type, company name, and date range, and returns metadata. It distinguishes itself from siblings like 'get_sec_filing' and 'search_sec_companies' by specifying the search behavior.

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?

Provides clear context on what parameters can be used, but does not explicitly state when to use this tool versus alternatives like 'get_sec_filing' for a specific filing. No exclusions or when-not-to scenarios are mentioned.

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/carrierone/verilexdata-mcp'

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