Skip to main content
Glama

get_related_filings

Return the other filings this filing cites. Call it after list_company_filings or get_filing_parsed, with the aann_ id they returned, when you need the paper trail around a filing rather than the filing alone.

Chinese listed companies print a filing number on most of their filings (e.g. 2026-047) and later filings cite it in their text. This tool follows those citations. Matching is exact and scoped to the same company — those numbers are per-company yearly counters and collide across the market, so a cross-company match would be wrong, not merely noisy.

Unlike get_filing_parsed this has NO recency window: you can ask about a filing of any age. What comes back is title, date and id, so you can feed any aann_ straight back into get_filing_parsed — that step is the one limited to recent filings.

Read the empty case carefully, because two different facts look similar. found=false means we hold no such filing id. found=true with an empty related means we do hold it and it cites nothing we have. own_number tells you the other half of the story: when it is null, this filing prints no number of its own, so nothing can cite it either. About a third of filings carry no printed number, so an empty result is ordinary rather than a sign of missing data.

WHERE COVERAGE ENDS: every filing whose text we hold has been scanned for citations, so an empty related on those is a real answer, not a gap. What is still incomplete is the corpus itself — a sizeable part of the archive is crawled but not yet parsed, and a filing we have not parsed cannot appear on either side of a citation. So a cited filing may be missing simply because we have not processed it yet, which is also why matched_no is worth reading: it names the number that was cited, even when we can only resolve some of them.

aevt_ on an entry is null when the cited filing produced no event. That is normal: we extract only a few event types so far (list_coverage names them), and the citation link itself does not depend on extraction.

Do NOT use this to sweep a company or the market: it takes a single filing id, has no cursor, and follows citations one hop at a time. Do NOT expect the cited filing's text here either — this returns identity only; pass the aann_ to get_filing_parsed for text, and note that step does have a recency window.

Input Schema

NameRequiredDescriptionDefault
aann_YesOpaque filing id from list_company_filings, e.g. aann_Kyw46MM1gCnIaBxA.
limitNoMax related filings to return. See limits.related_limit_max.

Output Schema

NameRequiredDescriptionDefault
codeNo
aann_No
foundYesFalse means we hold no filing under this id at all. An empty `related` list with found=true is a different answer: we have the filing, it just does not cite any filing we hold.
titleNoOriginal Chinese title. Never translated.
marketNo
reasonNounknown_filing = no such filing id.
relatedNoNewest first. Each entry includes {aann_, title, ann_date, matched_no, extractions, aevt_, event_type}. matched_no is the printed number that tied the two together. extractions is the complete event list; aevt_ and event_type are a single compatibility representative. They are null when the cited filing produced no event. See list_coverage for supported types.
ann_dateNoFiling date, YYYY-MM-DD.
returnedNo
disclaimerYes
own_numberNoThis filing's OWN printed number, or null when its text does not carry one (about a third do not). This is also why other filings may fail to link here: without a printed number there is nothing for them to cite.
more_availableNoTrue when there may be more beyond `limit`. There is no cursor; raise limit (max in list_coverage) if you need more.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so richly: exact same-company matching rationale, absence of a recency window (unlike get_filing_parsed), single-id/no-cursor/one-hop-at-a-time constraints, and the aevt_ null explanation. The empty-case semantics (found=false vs found=true with empty related vs own_number null) are disclosed in detail.

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 ordered into scoping, coverage limits, empty-case reading, and exclusions. It is long, but the length is largely justified by the tricky citation/coverage semantics that no annotation covers. A few sentences (e.g. the own_number aside) border on over-explanation.

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 citation-following tool with no annotations and subtle empty-result semantics, the description is complete: it covers call order, matching scope, coverage boundaries ('a sizeable part of the archive is crawled but not yet parsed'), and the meaning of every notable return field. An agent has everything needed to call it correctly and interpret the result.

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 coverage is 100%, so both parameters are already documented in the schema. The description adds lifecycle context for `aann_` (where to obtain it, that it can be fed back to get_filing_parsed) but says little about `limit` beyond implying there is no cursor. Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Return the other filings this filing cites.' It immediately distinguishes itself from siblings by framing the output as 'the paper trail around a filing rather than the filing alone,' and repeatedly contrasts with get_filing_parsed. An agent can tell exactly what this returns.

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 call-order guidance ('Call it after list_company_filings or get_filing_parsed, with the `aann_` id they returned'), explicit purpose condition, and explicit exclusions ('Do NOT use this to sweep a company or the market'). Alternatives (get_filing_parsed for text) are named with the condition that selects them.

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.