Skip to main content
Glama
Sign In
orbit-sentinel-mcp

orbit-sentinel-mcp

by Viventine-Space
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

search_sec_filings

Read-only

Search SEC filings for tracked space companies by ticker, CIK, company, form type, or date, or fetch one filing by accession number to surface financial signals such as recent 8-Ks.

Instructions

Search SEC filings for tracked space companies (8-K material events, 10-Q, 10-K). Filter by ticker, CIK, company name, resolved entity, form type, or date, or fetch one filing by accession number. Use for financial signals — e.g. recent 8-Ks for a satellite operator.

Input Schema

NameRequiredDescriptionDefault
cikNoSEC CIK number
limitNoMax rows returned (default 50, max 100). The response total is the full match count regardless of limit; rows cannot be paged, so answer counting questions from total. Output keeps the rows that fit in about 40 KB and says how many it left out
sinceNoOnly filings on/after this date (YYYY-MM-DD)
untilNoOnly filings on/before this date (YYYY-MM-DD)
tickerNoCompany ticker (e.g. ASTS)
companyNoSubstring match on company name
entity_idNoFilter by resolved entity UUID
form_typeNoSEC form type (e.g. 8-K, 10-Q, 10-K)
full_excerptNoIf true, show each row's full stored text excerpt (up to 4,000 characters) instead of a 200-character preview on the first 10 rows; pair with a small limit
accession_numberNoSEC accession number, e.g. 0001415404-26-000042 (the 18 digits without dashes work too): fetch that one filing, e.g. one listed in an entity dossier

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.10.0
    • addedInput schema / properties / full_excerpt
      Added value: +{
+  "description": "If true, show each row's full stored text excerpt (up to 4,000 characters) instead of a 200-character preview on the first 10 rows; pair with a small limit",
+  "type": "boolean"
+}
    • addedInput schema / properties / until
      Added value: +{
+  "description": "Only filings on/before this date (YYYY-MM-DD)",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.8.0
    • addedInput schema / properties / accession_number
      Added value: +{
+  "description": "SEC accession number, e.g. 0001415404-26-000042 (the 18 digits without dashes work too): fetch that one filing, e.g. one listed in an entity dossier",
+  "type": "string"
+}
  3. Changed1 schema field changedv0.7.0
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default 50, max 500)"New value: +"Max rows returned (default 50, max 100). The response total is the full match count regardless of limit; rows cannot be paged, so answer counting questions from total. Output keeps the rows that fit in about 40 KB and says how many it left out"
  4. First observedv0.3.1

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so safety is covered. The description adds real behavioral value by disclosing a second operating mode (single-filing retrieval by accession number), which an agent could not infer from the annotations, but says nothing about authentication or corpus coverage boundaries.

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 tight sentences: the scope and form types are front-loaded, followed by the filtering/fetch-mode summary and a use case. No waste or repetition.

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?

For a 10-parameter read-only search tool with no output schema, the description plus rich schema descriptions give enough to call it correctly, including the single-filing path. Response shape (row fields) is only implicitly conveyed, which is a minor gap.

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 description coverage is 100%, and the schema itself carries the substantive semantics (limit vs total, 40 KB truncation, full_excerpt behavior, accession number formats). The description only lists the filter categories, adding little beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource (search SEC filings for tracked space companies) and enumerates the covered form types (8-K, 10-Q, 10-K) plus a single-filing fetch mode. It does not differentiate itself from the similarly named sibling search_filings, leaving the agent to infer which corpus each covers.

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 a concrete usage context — financial signals such as recent 8-Ks for a satellite operator — and clarifies the alternate mode (fetch one filing by accession number). It stops short of naming when to prefer search_filings or get_filing_detail instead.

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

Deploy Server

Other Tools