AStockEvent

get_event_with_context

Return one specific filing event together with its full timeline (every stage the case went through, each with its own source PDF) and which subject's state it changed. Call this after another tool handed you an event id and you need the whole thread rather than a one-line summary — for example to see how a penalty case progressed from filing to decision.

Do NOT call this without an event id from a previous response: ids are opaque and cannot be guessed or constructed. Internal database identifiers are rejected.

affects_state lets you jump back to get_entity_state. Its subjects[].aent_ may be null when entity resolution has not run yet or does not apply — in that case use the code and market from the same affects_state, which never depends on entity resolution. If the id is unknown you get found=false, which is an answer, not an error: do not retry.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`aevt`	Yes	Opaque event id from a previous response. Must start with 'aevt_'.
`locale`	No	Language of data labels only.	en

Output Schema

TableJSON Schema

Name	Required	Description
`event`	No	The event itself, including source_pdf_url.
`found`	Yes
`reason`	No
`timeline`	No	Every frame of this case, newest first; each frame carries its own source_pdf_url.
`disclaimer`	Yes
`affects_state`	No	Which subject's state this changed: {code, market, subjects[]}. Use it to jump back to get_entity_state. Note subjects[].aent_ can be null when entity resolution is pending or not applicable — in that case use code+market, which never depends on entity resolution.
`coverage_since`	No
`possible_related_filings`	No	Possible links to filings, each with aann_, title, ann_date, relation='possible_relation', reason, evidence_aanns and decided_at. These can change with new evidence and do not establish event identity.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well: it explains that ids are opaque and must come from a previous response, internal database ids are rejected, unknown ids yield found=false rather than an error, and callers should not retry. It also discloses the timeline/source-PDF behavior and the affected-state linkage.

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?

The purpose is front-loaded and the guidance is dense rather than padded. The final paragraph contains useful but somewhat output-oriented detail about affects_state and null subjects, which is relevant but slightly less essential given that an output schema exists.

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 no-annotation tool with an output schema, the description is complete enough for correct invocation: it explains when to call, the provenance constraint on the id, invalid-id behavior, and how to use the resulting state linkage. Nothing critical for an agent to call it safely and correctly appears to be 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 coverage is 100%, so the schema already documents both parameters. The description adds useful semantic detail for the required aevt parameter, including its provenance, opacity, required prefix, and rejection of internal identifiers; locale is left to the schema.

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?

The description states a specific verb and resource: return one specific filing event plus its full timeline, source PDFs, and affected subject state. It clearly distinguishes this from a one-line summary and frames the tool as a follow-up lookup after an event id has been obtained.

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?

It gives clear when-to-use guidance (after another tool returns an event id and the full thread is needed) and explicit when-not-to-use guidance (do not call without an event id, ids cannot be guessed). It also mentions get_entity_state and a one-line-summary alternative, though it does not differentiate against all relevant sibling tools such as get_filing_parsed.

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

All AStockEvent 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.