Skip to main content
Glama

search

Read-onlyIdempotent

Unified search across every Aether corpus at once — SEC filings, Japan/EDINET and Korea/DART annual reports, EU financial regulation, and earnings calls/press-release exhibits — auto-routed and merged into one corpus-tagged, citation-complete result set. Use this for MOST questions: you do NOT have to pick the right corpus, and it will not miss same-day earnings (8-K earnings exhibits live in the transcript/press corpus, which a filings-only search silently misses). Each hit carries a corpus tag, an accession/citation string, a source URL, a 0-1 confidence score and an anchor_id. ALWAYS pass issuer (ticker, cik, or company_name for non-US filers) plus fiscal_year when you know it — it is forwarded to every corpus, so one named subject scopes filings and earnings calls together: fast and precise. A call with no issuer runs as scope=cross_company: slower, ranked by relevance only, and the response sets quality_caveat — check for that field before trusting the result. Use scope=cross_company deliberately, only for questions genuinely about many issuers ("which filers name NVIDIA as a supplier"). Filters are forwarded, not dropped: form_type / accession_number / section / return_format reach the filing corpora (sec/jp/kr), quarter and fiscal_year reach the earnings-call corpus, and EU regulation takes none of them (it has no issuer, form or quarter) — a filing filter therefore narrows an omitted corpora to sec/jp/kr. Any field not listed here is REJECTED with a 400 naming it, rather than silently ignored. Reach for financial_search / transcript_search / regulation_search only when you deliberately want to force a single corpus. Ownership questions do not go through search at all: holdings_by_security and holdings_by_manager.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax hits to return (1-50, default 10).
queryNoNatural language search query. OPTIONAL — omit it (or pass an empty string) to select FETCH MODE, which ranks nothing and returns rows in filing order. Fetch mode REQUIRES an identifier: pass `issuer` (ticker, cik or company_name) or a single-element `tickers`, optionally narrowed with `fiscal_year`; a query-less call with no identifier is rejected. Fetch fans out to sec/jp/kr/transcripts only — EU regulation has no issuer, so "every article, newest first" answers nothing.
scopeNoissuer (default): every corpus is scoped to the named company. cross_company: search all issuers — for questions like "who names NVIDIA as a supplier". Cross-company results are slower, relevance-ranked only, and always carry `quality_caveat`.issuer
issuerNoThe company the question is about. Pass at least one of ticker (e.g. "NVDA"), cik (e.g. "1045810"), or company_name (required for non-US issuers, which have no US ticker). Forwarded to every corpus that can use it. Strongly recommended on every call.
corporaNoOptional corpus filter. Omit to search everything (recommended). Values: sec, jp, kr, regulation, transcripts. An explicit value always wins: a filing filter (form_type / accession_number / section) narrows an OMITTED fan-out to sec/jp/kr, but naming corpora here overrides that.
quarterNoFiscal quarter(s) — "Q2" or ["Q1","Q2"]. Exact, case-insensitive. Applies to the EARNINGS-CALL corpus only (with issuer.ticker and fiscal_year it names one call, the natural fetch-mode request); the filing and regulation corpora ignore it.
sectionNoFiling section(s), matched case-insensitively as a substring of the stored label — "Item 1A" matches "Item 1A. Risk Factors". In fetch mode this is how you ask for one part of a filing. Filing corpora only; it narrows an omitted `corpora` to sec/jp/kr.
tickersNoLegacy alias of `issuer`, still accepted. One symbol (e.g. ["IBM"]) is read as issuer.ticker; several (e.g. ["IBM", "MU"]) is a cross-company question and is labelled scope=cross_company, though the filter to those companies still applies. Prefer `issuer`.
form_typeNoOnly return these filing forms, for example ["20-F"] or ["6-K"]. Forwarded to the filing corpora (sec/jp/kr). Because an earnings segment has no form type and an EU article has none either, setting this ALSO narrows an omitted `corpora` to sec/jp/kr rather than merging rows the filter could not reach.
fiscal_yearNoIssuer's fiscal year as the company labels it (NVIDIA FY2027 = year ending Jan 2027). Forwarded verbatim to every corpus: on filings it is resolved from XBRL DEI fiscal-year focus where available, else from the issuer's fiscal year-end; on earnings calls it is that corpus's own labelled fiscal year. An empty year widens ±1 with a caveat.
return_formatNoResponse shape for the filing corpora. "chunk" (the unified default) returns the matching window only — it keeps a five-corpus merge small. "section" returns the full SEC section the chunk belongs to, "both" returns both. The earnings-call and regulation corpora ignore it; their unit is a speaker turn / an article.chunk
accession_numberNoExact SEC accession number. When set, the filing corpora are hard-scoped to that filing, and an omitted `corpora` narrows to sec/jp/kr. It also counts as the identifier fetch mode requires, so `{accession_number}` with no `query` is a legal fetch.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo"search" = a `query` was given and hits are ranked by relevance. "fetch" = no `query`; the identifier and filters select rows and they come back in filing order, unranked.
queryYes
scopeNoEffective scope: the worst case across the corpora that answered. Any cross-company corpus makes the merged answer cross_company.
totalYes
resultsYes
latency_msYes
partial_errorsNo
quality_caveatNoPresent when any answering corpus was not issuer-precise. Read it before trusting the result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With annotations already covering safety (readOnlyHint, idempotentHint, destructiveHint=false), the description adds genuinely non-obvious traits: unknown fields are REJECTED with a 400 naming them rather than silently ignored, filters are forwarded rather than dropped, an omitted `corpora` is narrowed by filing filters, cross_company responses set `quality_caveat` that must be checked before trusting results, and each hit carries corpus/accession/URL/confidence/anchor_id.

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?

Front-loaded with purpose then usage then parameter guidance, and nearly every clause carries operational information. It is a long single block, though, and the dense parenthetical asides (e.g. EU regulation's lack of issuer/form/quarter) make it harder to scan than a short structured list would be.

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 12-parameter, nested-object, multi-corpus tool with an output schema, the description covers the decision path (default vs cross_company vs fetch mode), the identifier requirement, the forwarding/narrowing rules, and the response's quality_caveat sentinel. Nothing an agent needs to call it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents each field's format, so the baseline is 3; the description nonetheless adds cross-parameter routing semantics the schema does not (issuer is forwarded to every corpus so one named subject scopes filings and earnings calls together; fiscal_year forwarding and the empty-year ±1 widening; which filters reach which corpora). It stops short of adding syntax detail beyond the schema for most fields.

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+resource ('Unified search across every Aether corpus') and enumerates the exact scope: SEC filings, Japan/EDINET, Korea/DART, EU financial regulation, and earnings calls/press-release exhibits, auto-routed and merged. It also names the sibling tools (financial_search / transcript_search / regulation_search) it is distinct from, so an agent can route without opening other schemas.

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?

Explicitly states 'Use this for MOST questions' and that the caller does NOT have to pick a corpus, plus a concrete failure mode (same-day 8-K earnings exhibits silently missed by filings-only search). It gives a named condition and prohibition for scope=cross_company ('only for questions genuinely about many issuers') and routes ownership queries away from search entirely to holdings_by_security / holdings_by_manager.

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.