Current state folded from A-share filings — not a raw event dump.
An event feed tells you a plan was announced in June and amended in August. You still have to work out what is true today. This server does that fold for you: who is still selling down, which penalty cases are open, which inquiry letters are unanswered.
Every value links back to the source PDF published by the exchange, so you can check us.
This is a remote MCP server (Streamable HTTP). There is nothing to install — point your MCP client at the URL:
https://astockevent.com/mcp/No API key, no sign-up. Rate limits apply and the response tells you when you hit one.
{
"mcpServers": {
"astockevent": {
"url": "https://astockevent.com/mcp/"
}
}
}Prefer HTTP? The same data is available over REST — see
astockevent.com/docs, with the machine-readable
contract at /openapi.json.
Related MCP server: eastmoney-skills2mcp
Tool | What it answers |
| What is in scope and what the limits are. Call this before concluding data is missing. |
| Folded state for a company, or for a shareholder across every company they touch. |
| One event plus its whole timeline, in a single call. |
| What changed recently, cursor-paged. |
| Cross-company scan by filing type and date range. |
Three filing types today, stated plainly — more are being added. We would rather tell you the boundary than let you discover it by trial and error.
Type | Folded into |
Share reduction by major shareholders | The plan that is still live, and how much of its cap is used up |
Administrative penalty proceedings | Each case grouped by case number, folded to its current stage |
Exchange inquiry letters | Received / replied / overdue — the state of the conversation |
Call list_coverage for the authoritative, always-current answer.
Empty is not the same as unknown. A company with no filings of a type comes back as covered, nothing found — not as an empty result. A security we do not carry comes back as not found, with a reason. Telling those two apart is the point of this service.
We report, we do not judge. Objective extractions only: no ratings, no scores, no attribution of price moves. What you build on top of the facts is yours.
Pre-release. Coverage is narrow and stated honestly; the API may change.
If you are using it and something is missing or wrong, we want to hear it —
tell us here or email astockevent@outlook.com.
This repo is the public front door: what the server is, how to connect, and the
server.json descriptor for the MCP registry.
The server itself is remote — you point a client at a URL rather than installing code — so there is no server implementation to publish here. Extraction engines, crawlers and schemas live in a private repository.
MIT — see LICENSE.
Get the full detail for a single event by its event_id. Returns ALL fields: event metadata, structured_payload (quantitative fields specific to the event type), quantitative_tags, confidence_reasons, source info, timeline array, related events, and ai_summary. Use when: you have an event_id and need the complete event record — including type-specific fields in structured_payload that are not shown in list/search results. Do NOT use when: you only need the timeline (use get_event_timeline), or when you want to browse/search (use search_events_by_stock/type). Returns a single event object with all fields, or null if not found.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Event UUID v4. Example: 'c8a7f9e1-d2b4-4a3c-8d5e-1f6a9b3c7d4e' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds that it returns null if not found and lists all fields, which is useful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is fairly long but well-structured: starts with purpose, lists fields, then usage guidance. Every sentence is meaningful, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description compensates by listing all categories of returned fields. Annotations cover safety. Sibling tools provide differentiation. Complete for a single-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter event_id has 100% schema coverage with a description and example. The description reiterates 'by its event_id', but adds no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the full detail for a single event by event_id, listing all returned fields. It distinguishes from siblings like get_event_timeline and search events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (have event_id, need complete record) and when not to use (only need timeline or want to browse/search), with specific alternative sibling tools named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the lifecycle timeline and full detail for a single event. Tracks the event through its lifecycle: plan → in_progress → completed/terminated. Returns: full event detail + timeline array (each entry has date, phase, description) + related event IDs. Use when: you want to see the phase transitions and lifecycle history of an event you already know the event_id for. Do NOT use when: you want to search or browse events (use search_events_by_stock/type), or when you only need the summary fields (search_events_by_stock already returns ai_summary and key fields). Returns a single event object with timeline, or null if event_id is invalid or not found.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Event UUID v4. Example: 'c8a7f9e1-d2b4-4a3c-8d5e-1f6a9b3c7d4e' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds valuable behavioral context: returns timeline array with date/phase/description structure, null for invalid ID, and lifecycle phase transitions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (three sentences) and front-loaded with the main action. Each sentence serves a purpose: main function, lifecycle details, return structure, usage guidance, error case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description fully explains the return shape (full event detail + timeline array with date/phase/description + related IDs), covers the null error case, and provides usage boundaries. It is complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already provides a clear description and example for event_id. The description does not add additional semantic meaning beyond what the schema offers, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the lifecycle timeline and full detail for a single event' with specific verb and resource. It explicitly tracks lifecycle phases (plan → in_progress → completed/terminated) and distinguishes from sibling tools by focusing on a known event_id, not search/browse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (knowing event_id, want lifecycle history) and when not to use (searching, only need summary) with direct references to alternative tools (search_events_by_stock/type). This is a model example of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a trust and verification report for a single event. Returns: confidence_tier + confidence_score (heuristic 0-1), multi-source cross-validation details (which sources agree/disagree), and extraction quality metrics from the review system (regex vs LLM conflict count, llm_validation status, whether human-reviewed). Use when: you need to assess how reliable or trustworthy an event's extraction is — e.g. before making a trading decision based on the event data. Do NOT use when: you only need the event data itself (use get_event_detail), or when browsing/searching (use search_events_by_* tools). Returns a trust report object: {event_id, confidence_tier, confidence_score, confidence_reasons, cross_validation: {sources_checked, sources_agree, sources_disagree, source_details}, extraction_quality: {total_fields_reviewed, regex_llm_conflicts, llm_validation, human_reviewed}}.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Event UUID v4. Example: 'c8a7f9e1-d2b4-4a3c-8d5e-1f6a9b3c7d4e' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it details the return object structure (confidence_tier, confidence_score, cross-validation details, extraction quality metrics). Annotations already indicate read-only, non-destructive behavior, and the description aligns, providing no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose and usage guidelines, but the return object specification is somewhat verbose. Could be slightly more concise, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully specifies the return object. With only one parameter and clear usage context, the description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (event_id). The description does not add meaning beyond the schema's description, which is adequate. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a trust and verification report for a single event.' It uses a specific verb ('Get') and resource ('trust report') and explicitly distinguishes from sibling tools by naming alternatives (get_event_detail, search_events_by_*).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Do NOT use when' guidance, citing specific alternatives (get_event_detail, search_events_by_* tools). This fully informs the agent about appropriate invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get events due within the next N days — early warning for expirations and deadlines. Covers: lockup share expiration dates (限售股解禁到期), share reduction plan deadlines (减持计划到期), delisting period end dates (退市整理期结束), buyback implementation deadlines (回购实施到期), and regulatory letter reply deadlines (监管函回复截止日). Each result includes: event_id, event_type, stock_code, stock_name, due_date (ISO 8601 date, YYYY-MM-DD), days_remaining (integer countdown), and ai_summary. Use when: you need a forward-looking calendar — what lockup expirations, regulatory deadlines, or buyback periods are ending soon. Do NOT use when: you need historical event data or events without a future due date (use search_events_by_stock/type for general event queries). Returns a JSON array of upcoming events, ordered by due_date ascending (soonest first). Max look-ahead: 30 days. Only events with status=active|updating are included.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_codes | No | Comma-separated 6-digit stock codes. Empty = all stocks. | |
| days | No | Number of days to look ahead. Default: 7, Max: 30. | |
| event_types | No | Comma-separated event types to filter. Empty = all types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description focuses on additional behaviors: ascending due_date order, 30-day max look-ahead, and status filter (active|updating). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly efficient: uses clear sectioning (purpose, covered events, result fields, usage, constraints) without redundancy. Every sentence adds unique information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and multiple siblings, the description provides sufficient context: usage boundaries, result structure, ordering, and constraints. Adequate for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by enumerating the specific event types covered, which goes beyond the schema's generic 'event types' description. Slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's purpose: retrieving upcoming events within N days as early warnings. Lists specific event types (lockup expirations, deadlines) and differentiates from historical queries, avoiding ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use (forward-looking calendar) and when-not-to-use (historical data) with direct sibling alternatives (search_events_by_stock/type). No reliance on implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search convertible bond events (可转债事件). Covers: call_redemption (强赎/提前赎回), put_resale (回售), conversion_price_down (下修转股价), maturity (到期兑付). Each event includes: cb_name (可转债名称), cb_event_type (子事件类型), and type-specific quantitative fields like redemption_price, event_price, old_conversion_price/new_conversion_price, event_date, etc. Use when: you want convertible bond corporate action signals — forced redemption deadlines (强赎), put-back rights (回售), conversion price adjustments (转股价修正), or maturity redemption. Convertible bond events are a differentiated product — this tool provides the dedicated entry point for this event category. Returns: {data: [...], cursor: , has_more: bool}.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_codes | No | Comma-separated 6-digit stock codes. Empty = all stocks. Example: '113013,128091' for stock codes that issued convertible bonds. | |
| cb_event_type | No | Filter by convertible bond sub-event type. Options: call_redemption, put_resale, conversion_price_down, maturity. Empty = all types. | |
| status | No | Filter by event status: active, updating, closed, corrected, archived. | |
| cursor | No | Pagination cursor from previous response. | |
| limit | No | Max results per page. Default: 20, Max: 200. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint. Description adds return format {data, cursor, has_more} and lists type-specific fields like redemption_price, event_price, etc., supplementing the annotations effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured: purpose, event types, usage scenarios, return format. While slightly verbose, it is well-organized and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count (5) and absence of output schema, the description adequately covers purpose, event types, return format, and usage context. It could include more detail on response fields but remains complete for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter documented. The description does not add additional semantic meaning beyond the schema; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches convertible bond events and enumerates four specific sub-event types (call_redemption, put_resale, conversion_price_down, maturity). This differentiates it from sibling tools like search_dividend_events, search_regulatory_events, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use when: you want convertible bond corporate action signals — forced redemption deadlines, put-back rights, conversion price adjustments, or maturity redemption.' While it doesn't explicitly exclude alternatives, the context of many siblings makes the niche clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search dividend events (分红/送转). Pre-filtered to dividend. Use for dividend announcements, ex-rights dates, payout ratios.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_codes | No | Comma-separated stock codes. Empty = all. | |
| status | No | Filter by event status. | |
| cursor | No | Pagination cursor. | |
| limit | No | Max results. Default: 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the behavioral profile. Description adds use-case context but does not disclose additional behaviors (e.g., rate limits, auth). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two short, front-loaded sentences. Every sentence is informative: first states the tool's action and scope, second gives use cases. No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description partially explains output by listing specific fields (announcements, ex-rights, payouts). It does not cover pagination behavior or general output structure, but given the tool's simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds overall dividend context but does not elaborate on individual parameters beyond what the schema already provides. No parameter-specific enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Search dividend events' with Chinese translation, and specifies it is pre-filtered to dividends. It lists concrete use cases (announcements, ex-rights dates, payout ratios), clearly distinguishing from sibling search tools like search_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description tells the agent to use it for dividend-related queries, but does not explicitly state when not to use it or name alternatives. The guidance is clear and contextually sufficient, missing only formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Universal event search with all supported filters. This is the escape hatch for complex queries not covered by the specialized tools. Supports all filter combinations: stock_code, event_type, since (datetime), status, confidence_tier, shareholder_name. Use when: you need a multi-filter query that doesn't fit into the specialized tools — e.g. 'all verified share_reduction events for 002272 since 2026-05-01'. Do NOT use when: a specialized tool (search_events_by_stock, search_events_by_type, search_events_by_shareholder) would work — prefer specialized tools for better results. Supports cursor-based pagination. Returns: {data: [...], cursor: , has_more: bool}.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_codes | No | Comma-separated 6-digit stock codes. Empty = all. | |
| event_types | No | Comma-separated event types. Empty = all. | |
| event_type | No | Single event type (backward-compat alias for event_types). Merged with event_types if both provided. | |
| severity | No | Filter by AI context severity: red, yellow, green. Comma-separated for multiple. Requires ai_context from DEV-84. | |
| sentiment | No | Filter by AI context sentiment: positive, negative, neutral. Comma-separated for multiple. Requires ai_context from DEV-84. | |
| since | No | ISO 8601 datetime or YYYY-MM-DD. Filter events updated after this time. | |
| status | No | Filter by event status: active, updating, closed, corrected, archived. | |
| confidence_tier | No | Filter by confidence: verified, likely, uncertain. | |
| shareholder_name | No | Filter by shareholder name in structured_payload. | |
| cursor | No | Pagination cursor from previous response. | |
| limit | No | Max results per page. Default: 20, Max: 200. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by detailing cursor-based pagination and the exact return format ({data, cursor, has_more}), beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of four sentences that are front-loaded with the tool's purpose and include all essential information without redundancy. Every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 optional parameters and no output schema, the description covers the purpose, usage boundaries, return format, and pagination. Could mention error handling or rate limits but is sufficiently complete for a search tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 lists filter names but adds no parameter-specific semantics beyond what the schema already provides (e.g., format, defaults, allowed values). Adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a universal event search with all supported filters, explicitly distinguishing it from specialized siblings (e.g., search_events_by_stock) by calling itself an 'escape hatch' for complex queries. This aligns with a specific verb+resource with scope differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Do NOT use when' guidance, including a concrete example query and naming specific sibling tools to prefer. This gives an agent clear decision criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query structured A-share announcement events by stock code(s). Returns events for: share_reduction (减持), delisting_risk (ST/退市), regulatory_letter (监管函/问询函), lockup_expiration (限售解禁), share_buyback (回购). Each event includes: event_id, event_type, stock_code, stock_name, ai_summary, confidence_tier, structured_payload, and announcement_date. Use when: you know the stock code(s) and want to check recent events for those stocks. Use this for portfolio monitoring, watchlist scanning, or single-stock deep dives. Do NOT use when: you want to search by event type across all stocks (use search_events_by_type), or when you need a specific shareholder's events (use search_events_by_shareholder). Supports cursor-based pagination — use the cursor field in the response to fetch the next page. Returns: {data: [...], cursor: , has_more: bool}.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_codes | Yes | Comma-separated 6-digit stock codes. Example: '002272,600519,300750'. | |
| status | No | Filter by event status. Options: active, updating, closed, corrected, archived. Empty = active + updating. | |
| confidence_tier | No | Filter by confidence tier. Options: verified, likely, uncertain. Empty = all. | |
| cursor | No | Pagination cursor from previous response. Leave empty for first page. | |
| limit | No | Max results per page. Default: 20, Max: 200. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety. The description adds value by explaining cursor-based pagination and the response structure, which are beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized paragraph that front-loads the purpose, lists event types, provides usage guidance, and explains pagination. It is concise without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully describes the return fields (event_id, event_type, etc.) and pagination response format. It covers all 5 parameters implicitly and provides sufficient context for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds minor value such as an example for stock_codes and explanation of cursor usage, but does not significantly augment the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query structured A-share announcement events by stock code(s)' and lists specific event types (share_reduction, delisting_risk, etc.), distinguishing it from siblings like search_events_by_type and search_events_by_shareholder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you know the stock code(s)') and when not to, providing two named alternatives (search_events_by_type, search_events_by_shareholder). This helps the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query structured A-share announcement events by event type(s). Event types: share_reduction, delisting_risk, regulatory_letter, lockup_expiration, share_buyback. Use when: you want to find all events of a specific type across the market — e.g. all recent share reductions, all ST/delisting warnings, all regulatory letters. Do NOT use when: you know the stock code(s) (use search_events_by_stock), or when you need a complex multi-filter query (use search_events). Supports cursor-based pagination — use the cursor field in the response to fetch the next page. Returns: {data: [...], cursor: , has_more: bool}.
| Name | Required | Description | Default |
|---|---|---|---|
| event_types | Yes | Comma-separated event types. Example: 'share_reduction,delisting_risk'. | |
| status | No | Filter by event status. Options: active, updating, closed, corrected, archived. | |
| confidence_tier | No | Filter by confidence tier. Options: verified, likely, uncertain. | |
| cursor | No | Pagination cursor from previous response. Leave empty for first page. | |
| limit | No | Max results per page. Default: 20, Max: 200. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, idempotent, and open-world. The description adds valuable behavioral context: cursor-based pagination, return format with cursor/has_more, and market scope (A-share announcements).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence for purpose, one for event types, one for usage guidance, one for pagination, one for return format. Front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers return format, pagination, event types, and usage context. With 5 parameters fully described in schema and rich annotations, the description is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameter descriptions. The description adds event type examples and pagination context, but does not significantly augment the schema's explanations beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries A-share announcement events by type, lists specific event types, and distinguishes itself from sibling tools (search_events_by_stock, search_events) by scope and usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' and 'Do NOT use when' sections with clear alternatives (search_events_by_stock, search_events) provide excellent guidance on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search fund penetration events — cross-reference a fund's underlying stock holdings with AStockEvent structured events. Returns a weighted event feed sorted by impact_score = weight_pct × severity_weight. Covers all 13 A-share event types: share_reduction, delisting_risk, regulatory_letter, lockup_expiration, share_buyback, asset_restructuring, trading_halt_resume, pledge_risk, earnings_forecast, share_increase, dividend, violation_penalty, cb_event. Use when: you have a fund code and want to know what events happened to its underlying holdings — e.g. monitoring FOF portfolio risk, fund due diligence, or checking 'did my fund's heavy-weight stocks have any regulatory issues recently?'. Each event includes: stock_code, stock_name, weight_pct, event_type, event_summary, impact_score, severity_weight, confidence_tier. The response includes fund_info, holdings list, events sorted by impact_score DESC, a summary with total_events/affected_holdings_count/affected_weight_pct/top_risk, and a data_freshness disclaimer noting holdings are from the latest quarterly report. Free tier: Top 10 holdings only. Paid REST tier: full holdings + extended lookback.
| Name | Required | Description | Default |
|---|---|---|---|
| fund_code | Yes | 6-digit fund code. Example: '000001' for 华夏成长混合. | |
| event_types | No | Comma-separated event types to filter. Empty = all 13 types. | |
| days | No | Number of days to look back for events. Default: 30, Max: 90. | |
| min_weight | No | Minimum holding weight_pct to include (e.g. 5.0 = only stocks with ≥5% weight). Default: 0 (all holdings). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description additonally discloses important behavioral traits: data freshness from latest quarterly report, free tier limits (top 10 holdings), paid tier full holdings, and ordering by impact_score. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and each sentence adds value. It is relatively long but well-structured. Minor redundancy could be trimmed, but overall it is effective and earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema), the description adequately covers the output structure, data freshness, tier limits, and sorting. It lacks error handling details, but the essential context for an agent to use the tool is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant new meaning for parameters beyond the schema, though it provides context like free tier limits which relate to the fund_code parameter indirectly. Overall, minimal added value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches fund penetration events by cross-referencing holdings with stock events, specifying the output as a weighted event feed sorted by impact_score. It distinguishes from sibling tools by focusing on fund-level event aggregation, which is unique among the listed search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides use cases (e.g., monitoring FOF portfolio risk, fund due diligence) and conditions (have a fund code). However, it does not mention when NOT to use it or contrast with alternatives like search_events_by_stock, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search regulatory events (监管函/问询函). Covers regulatory_letter, violation_penalty. Use for regulatory scrutiny signals from exchanges.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_codes | No | Comma-separated stock codes. Empty = all. | |
| status | No | Filter by event status. | |
| cursor | No | Pagination cursor. | |
| limit | No | Max results. Default: 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so description does not need to cover those. The description adds value by detailing the event types covered ('regulatory_letter, violation_penalty'), which is beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Front-loaded with purpose and specific coverage. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema) and rich annotations, the description is complete enough. It specifies the event types and usage context. Missing output schema details are not required when description focuses on input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description does not add additional meaning beyond what the schema provides. Baseline score of 3 is appropriate as the description does not harm but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for regulatory events, specifically covering 'regulatory_letter' and 'violation_penalty' types. This distinguishes it from sibling tools like 'search_violation_events' or 'search_events' by specifying the exact event coverage. The annotation title adds clarity with 'exchange scrutiny'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for regulatory scrutiny signals from exchanges, but does not explicitly state when not to use or list alternative tools. However, by specifying coverage of specific event types, it indirectly guides the agent away from tools for other event types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search asset restructuring events (重大资产重组). Use for M&A, asset injections, spin-offs, reverse mergers.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_codes | No | Comma-separated stock codes. Empty = all. | |
| status | No | Filter by event status. | |
| cursor | No | Pagination cursor. | |
| limit | No | Max results. Default: 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the description does not need to repeat those. The description adds no behavioral details beyond those annotations, but also does not contradict them. It is adequate but adds minimal contextual color (e.g., the Chinese term suggests localization).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences fulfill all essential purposes: stating the function, providing a Chinese translation, and listing use cases. No extraneous words; every phrase adds value. Does not repeat structured data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely complete for a search tool with good parameter schema, though it does not describe the output format or pagination behavior. However, given the annotations (readOnlyHint, openWorldHint) and presence of cursor/limit parameters, the expected behavior is inferable. A brief note on return structure would raise it to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with descriptions for all 4 parameters, so the baseline is 3. The description provides no additional parameter-level information beyond the schema; it only adds high-level event context. This is acceptable but does not elevate the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' and clearly identifies the resource as 'asset restructuring events (重大资产重组)'. It lists concrete event types (M&A, asset injections, spin-offs, reverse mergers), which distinguishes it from sibling tools like 'search_events' or 'search_cb_events'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use for M&A, asset injections, spin-offs, reverse mergers', providing clear context on when to use this tool. However, it does not mention when not to use it or suggest alternatives among the many sibling tools, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search risk events (ST/退市风险/质押风险/停复牌/限售解禁). Covers delisting_risk, pledge_risk, trading_halt_resume, lockup_expiration. Use for early warning signals.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_codes | No | Comma-separated stock codes. Empty = all. | |
| status | No | Filter by event status. | |
| cursor | No | Pagination cursor. | |
| limit | No | Max results. Default: 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's safety profile is clear. The description adds context about covered risk event types but does not disclose additional behavioral traits like pagination behavior or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. It front-loads the key information: what the tool does and what it covers, then adds a use-case hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with 4 well-documented parameters and no output schema, the description adequately conveys the scope (risk events types) and purpose. It could be more complete by hinting at the output format or differentiating from similar sibling tools, but it is sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description in the schema. The tool description does not add any parameter-specific details beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches risk events and lists specific types (delisting risk, pledge risk, etc.), making the purpose specific and actionable. However, it does not explicitly differentiate from sibling tools like 'search_events' or 'search_events_by_type', leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using it for 'early warning signals', providing a use case. However, it does not mention when not to use it or compare with alternatives among the 14 sibling tools, so guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search violation & penalty events (违规处罚/立案调查). Use for regulatory violations, investigations, penalties, fines.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_codes | No | Comma-separated stock codes. Empty = all. | |
| status | No | Filter by event status. | |
| cursor | No | Pagination cursor. | |
| limit | No | Max results. Default: 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds no additional behavioral traits beyond the tool's domain (violations/penalties), and does not discuss pagination, authentication, or other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core purpose and then specify usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, many siblings, no output schema), the description is adequate but minimal. It does not address pagination behavior or how to interpret results, and it lacks differentiation from similar tools like search_regulatory_events.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning to the parameters beyond the domain context, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches violation and penalty events for regulatory violations, investigations, penalties, fines, and includes a Chinese translation for clarity. However, it does not explicitly differentiate from the sibling tool 'search_regulatory_events', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage context (regulatory violations, investigations, penalties, fines) but does not provide when-not-to-use guidance or explicitly mention alternatives among the many sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1get_event_detailget_event_timelineget_trust_reportget_upcoming_eventssearch_cb_eventssearch_dividend_eventssearch_eventssearch_events_by_shareholdersearch_events_by_stocksearch_events_by_typesearch_fund_eventssearch_regulatory_eventssearch_restructuring_eventssearch_risk_eventssearch_shareholder_eventssearch_violation_eventsScored across 16 tools
Most tools have clearly distinct purposes, with specialized search tools for different event types. However, some overlap exists between search_risk_events, search_regulatory_events, and search_violation_events, which cover similar risk-related events.
Naming follows a consistent pattern: 'get_' for retrieval of specific items and 'search_' for querying, with descriptive suffixes like '_by_stock', '_by_type', or category names like '_cb_', '_dividend_'. There is no mixing of conventions.
16 tools is slightly on the higher side but appropriate for the breadth of event types covered. The specialized search tools reduce cognitive load by pre-filtering, and the generic search_events serves as an escape hatch.
The tool surface is comprehensive for querying a wide range of A-share events, including specialized searches and detail retrieval. Missing are creation, update, or delete operations, which may be out of scope for a read-only data server.
China A-share market data for research, backtesting and AI agents via MCP.
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
Financial data and research MCP for US/CN/JP equities: filings, statements, ownership, signals.
Structured company & industry news for AI agents: typed, dated, source-linked events.
