aether-developer

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. With an issuer and no corpora, EU regulation is not searched; if the issuer yields no SEC or earnings hit the response is empty with coverage: "none" and a quality_caveat, never filled from other corpora. partial: true means a corpus arm failed: retry before concluding absence. Returned windows overlap; counts of a term over returned text are not document counts. To page through a long document past limit, use financial_search / transcript_search fetch mode with offset. Ownership questions do not go through search at all: holdings_by_security and holdings_by_manager.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Max hits to return (1-50, default 10).
`query`	No	Natural 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.
`scope`	No	issuer (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
`issuer`	No	The 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.
`corpora`	No	Optional 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.
`quarter`	No	Fiscal 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.
`section`	No	Filing 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.
`tickers`	No	Legacy 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_type`	No	Only 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_year`	No	Issuer'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_format`	No	Response 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_number`	No	Exact 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

Name	Required	Description
`mode`	No	"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.
`query`	Yes
`scope`	No	Effective scope: the worst case across the corpora that answered. Any cross-company corpus makes the merged answer cross_company.
`total`	Yes
`partial`	No	True when a corpus arm failed (timeout or error). The result is incomplete; retry before concluding something is absent.
`results`	Yes
`coverage`	No	Issuer-scoped calls only: "none" means the named issuer produced no SEC filing or earnings-call/press hit. `results` is then empty ON PURPOSE (never filled with other corpora) and `quality_caveat` says whether the issuer is unindexed or the filters matched nothing.
`latency_ms`	Yes
`failed_corpora`	No
`issuer_indexed`	No	With coverage "none": false = the issuer is not in Aether's index; true = indexed, but these filters matched nothing.
`partial_errors`	No
`quality_caveat`	No	Present when any answering corpus was not issuer-precise. Read it before trusting the result.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 10, 2026

addedOutput schema / properties / coverage

Added value: +{
+  "description": "Issuer-scoped calls only: \"none\" means the named issuer produced no SEC filing or earnings-call/press hit. `results` is then empty ON PURPOSE (never filled with other corpora) and `quality_caveat` says whether the issuer is unindexed or the filters matched nothing.",
+  "enum": [
+    "none"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / failed_corpora

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / issuer_indexed

Added value: +{
+  "description": "With coverage \"none\": false = the issuer is not in Aether's index; true = indexed, but these filters matched nothing.",
+  "type": "boolean"
+}

addedOutput schema / properties / partial

Added value: +{
+  "description": "True when a corpus arm failed (timeout or error). The result is incomplete; retry before concluding something is absent.",
+  "type": "boolean"
+}

First observedSep 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already carry readOnly/idempotent/destructive=false, and the description still adds substantial behavior: quality_caveat on cross-company, coverage:none empty results, partial:true on arm failure, 400 on unknown fields, EU exclusion with issuer+no corpora, and overlapping windows. Slightly long-winded but genuinely informative beyond annotations.

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

Conciseness3/5

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

Front-loads purpose well, but it is dense and sprawling with many mid-sentence caveats and parentheticals; several behaviors (partial, overlap, ownership routing) could be tightened or reside in schema. It earns most of its length but is not tightly structured.

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?

Given 12 params, nested issuer, output schema present, this describes empty-result semantics, partial failures, caveat fields, filter forwarding, and paging escape hatches. An agent has everything needed to call correctly and interpret results.

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%, so baseline is 3; the description still adds routing logic not obvious from schema alone (filters forwarded not dropped, form_type narrowing omitted corpora to sec/jp/kr, EU taking no filters, accession counting as fetch identifier). Marginal overlap with schema descriptions, so not a 5.

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?

States a specific verb and resource: unified search across all corpora, names the corpora covered, and distinguishes it from siblings by naming financial_search/transcript_search/regulation_search as the single-corpus alternatives. An agent knows exactly what this does and how it differs from every sibling.

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?

Explicit when-to-use ("MOST questions", don't pick a corpus), when to use siblings (only to force a single corpus), when to use cross_company (deliberately, many-issuer questions), routing of ownership questions to holdings_by_* tools, and paging to fetch mode. This is about as complete a routing spec as exists.

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

All aether-developer tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.