Skip to main content
Glama

AStockEvent

get_filing_parsed

Return ONE filing already parsed for you: its available normalised text and its tables as structured cells. Call it after list_company_filings, with the aann_ id that tool returned, when you need what a filing actually says rather than just its title and PDF link.

This is the step your own pipeline would otherwise have to do: a filing PDF is a layout format, not a data format, so pulling clean text and real table cells out of it is where ad-hoc extraction usually goes wrong. Tables come back as rows of cells you can read directly, not as an image or a flattened blob.

It serves ONE filing per call, whose date is at most seven days before the database current date (eight calendar dates including today). Older filings are not gone — the filing itself and its source PDF link stay available from list_company_filings for the company's whole history; only the parsed text is recent-only. When that is why you got nothing, reason says outside_parsed_window, which is a different answer from unknown_filing.

Source coverage is limited: PDFs over 150 pages are parsed only through the first 30 pages; table coverage is limited above 50 pages. Use source links for the complete original. text_chars measures stored text, not source completeness. text_truncated=false or next_text_offset=null does not mean every PDF page was parsed.

Stored text arrives in slices: read text_chars for the stored total and call again with next_text_offset until it is null. Do NOT use this to sweep a company or the market — it takes a single filing id and has no cursor.

Read text_unavailable before trusting the text. Two of its values are properties of the source file — a scan with no text layer, or a font we cannot map to Unicode — and retrying those will not help. A third, parse_failed, means the failure is ours rather than the document's, and asking again later may well work. Either way the source links are still worth opening.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aann_YesOpaque filing id from list_company_filings, e.g. aann_Kyw46MM1gCnIaBxA.
text_offsetNo0-based offset into the filing's full text. Start at 0; then pass next_text_offset from the previous call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo
noteNo
textNoNormalised plain text of this filing, from `text_offset`, at most `limits.parsed_text_chunk_chars` characters per call.
aann_No
foundYesFalse means either we hold no filing under this id, or the filing is outside the parsed-text window. Read `reason` to tell those apart.
titleNoOriginal Chinese title. Never translated.
marketNo
reasonNounknown_filing = no such filing id. outside_parsed_window = the filing exists and its source PDF is still available from list_company_filings, but parsed text is only served for recent filings.
tablesNoTables as cells, in document order: {index, page, n_rows, n_cols, cells, continuation_of}. continuation_of points at the table this one continues from when a table spans pages. Empty list means this filing has no tables.
sourcesNoEvery source link we hold for this filing, best first. Use them to check our text against the original.
ann_dateNoFiling date, YYYY-MM-DD.
parsed_atNoWhen we parsed it.
disclaimerYes
text_charsNoLength of stored parsed text, which may cover only part of the PDF. Compare with text_offset + len(text) to see how much is left.
table_countNo
text_offsetNo
window_daysNoMaximum filing-date age in database calendar days, inclusive of age zero.
text_truncatedNoTrue when more stored text follows. False does not guarantee full PDF coverage.
next_text_offsetNoWhere to continue, or null at the end of stored text, not necessarily the source PDF.
text_unavailableNoWhy the text cannot be used, or null when it can. no_text_layer = the source PDF carries no text layer at all (a scan), so there is nothing to extract. unreadable_font_encoding = it has text, but the PDF embeds a subset font without a Unicode map, so the characters come out as (cid:NNNN) placeholders; the text is still returned, and the numbers and structure may still be readable, but the words are not. Those two are properties of the source file — re-requesting will not help. parse_failed means the failure is OURS, not the document's: we did not parse it successfully, and it is worth asking again later. Check this field rather than testing whether `text` is empty.

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 no annotations the description carries the full burden, and it delivers: seven-day recency window with reason=outside_parsed_window vs unknown_filing, page-limit parsing caveats, paginated text slices via next_text_offset, and a taxonomy of text_unavailable values including which are retryable. This is unusually rich behavioral disclosure.

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 the core purpose, then window limits, then caveats, then pagination. Every paragraph carries distinct information, though the seven-day window is explained across three sentences and the piece is on the long side. No filler, but tightening is possible.

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?

An output schema exists, so return values needn't be described, yet the description goes further and covers return-value semantics (text_chars, text_truncated, next_text_offset, text_unavailable, reason) plus recency and coverage limits. Nothing an agent needs to call this correctly is missing.

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 description coverage is already 100%, so the baseline is 3; the description adds value by specifying the aann_ id's provenance (must come from list_company_filings) and the pagination contract for text_offset/next_text_offset. It stops short of naming the parameter text_offset explicitly, but the semantics are clear from context.

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 ('Return ONE filing already parsed... normalised text and tables as structured cells') and distinguishes itself from list_company_filings by contrast (what a filing says vs its title and PDF link). An agent can tell it apart from siblings without opening any schema.

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: after list_company_filings, using the aann_ id it returned, when you need filing content. Explicit when-not: 'Do NOT use this to sweep a company or the market — it takes a single filing id and has no cursor.' Also routes to alternatives (source links, list_company_filings) for older filings.

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.