Skip to main content
Glama

AStockEvent

get_entity_state

Return what is true RIGHT NOW about one A-share listed company or one shareholder entity, folded from its regulatory filings: pending and executed share-reduction plans, administrative-penalty proceedings, and exchange inquiry letters. Call this when you need the current situation of a specific subject — for example 'is this shareholder still selling', 'is this company under investigation', 'has it replied to the inquiry letter'.

Do NOT call this to find out what happened across the market recently — use scan_recent_events or whats_new for that. Do NOT pass both (code, market) and aent_; pick one addressing mode.

Read the response in this order and stop at the first match: (1) found=false -> we do not cover this security/entity, do not retry; (2) visibility='hidden_unverified' -> the entity exists but its identity is not human-verified, so its name is withheld; query by code+market instead; (3) resolved_as='listed_company' -> your aent_ denoted the company itself and the request was redirected, use the returned code/market; (4) has_events=false -> the security EXISTS but had no covered filings in the covered period (this is the common case, ~85% of valid lookups) — report 'no filings in period', never 'company not found'; (5) companies=[...] -> a shareholder active across one or more companies, read each entry; (6) otherwise the state machines apply to that one company.

Fields that separate 'did not happen' from 'we do not know' are load-bearing: current_holding_reason, window_status ('expired_no_closure' = the plan window lapsed with no closing filing), entity_link, entities_status, plan_pairing ('unresolved' = several open plans and we refuse to guess the pairing), and unclassified_count. Never collapse them into 'nothing there'. Values are objective extractions with a source PDF link; we never rate, score or attribute.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoSecurity code, e.g. '000029'. Must be given together with market.
aent_NoOpaque entity id taken from a previous response. Never construct or guess one. Mutually exclusive with code/market.
localeNoLanguage of human-readable data labels only; errors and this description are always English.en
marketNoOne of ['SH', 'SZ', 'BJ']. Required when code is given.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
foundYesFalse means we do not have this security/entity at all.
reasonNoPresent only when found=false: 'unknown_security' or 'unknown_entity'.
companiesNoPresent for shareholder entities: one entry per company, each carrying the same state machines. An empty list means the entity exists but has no linked filings — not that the person did nothing.
disclaimerYesAlways present. Objective facts only, no ratings.
has_eventsNoFalse means the security EXISTS but has no filings of the covered types in the covered period. This is NOT the same as found=false.
visibilityNoEntity exists but its identity is not human-verified; its name and linked filings are withheld. Query by (code, market) instead.
resolved_asNoThe aent_ you passed denotes the listed company itself; the request was redirected. Use the returned code/market to attribute this state.
coverage_sinceNoEarliest filing date we cover. Data before this is absent.

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 provided, the description carries the full behavioral burden and does so richly: found=false means do-not-retry, hidden_unverified withholds the name, ~85% of valid lookups return no filings (pre-empting a false 'not found'), and it flags the load-bearing fields (window_status, plan_pairing, unclassified_count) that separate 'did not happen' from 'we do not know'. It also discloses that values are objective extractions with source PDFs and are never rated or scored.

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 and usage before the response-reading protocol, and every sentence carries real information. It is nonetheless long and the ordered response-interpretation list overlaps with what an output schema could convey, so it is efficient rather than maximally tight.

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 tool whose output schema already exists, the description still supplies everything needed to interpret edge cases: the resolution order, the resolved_as redirect, the common no-events case, and the meaning of the ambiguous fields. Nothing an agent needs to call or correctly read this tool 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 coverage is 100%, so all four parameters are already documented, making 3 the baseline. The description adds enforcement value beyond the schema by restating the mutual exclusivity of (code, market) vs aent_ and the need to pick a single addressing mode, which reduces misuse of the two-mode interface.

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?

Specific verb ('return what is true RIGHT NOW') plus a tightly scoped resource (one A-share listed company or shareholder entity) and a clear delineation from the market-wide siblings. An agent can distinguish this from get_filing_parsed, scan_recent_events, or whats_new without opening a 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?

Explicitly states when to call ('is this shareholder still selling', investigation, inquiry-letter status) and when NOT to call, naming the exact alternatives (scan_recent_events, whats_new) for the market-wide case. It also enforces the addressing-mode rule so the agent cannot pass conflicting parameters.

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.