AStockEvent

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation4/5
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 Consistency5/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 4.2/5 across 16 of 16 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on June 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating safe, read-only behavior. The description adds the coverage of specific event types but does not disclose additional behavioral traits beyond what the schema (pagination via cursor/limit) provides. Overall, the description adds some context but is not rich in behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only two sentences—with the purpose front-loaded. Every sentence provides essential information (what the tool does and what it covers) without any redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description could have explained the return format or the nature of the events returned (e.g., details provided). It does not do so, leaving the agent to infer the output from the tool name. The description is adequate but not fully complete for a search tool without output schema.
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 description coverage is 100%, so the schema already documents all parameters. The description does not add any extra meaning or usage details beyond the schema. Therefore, it meets the baseline but does not enhance understanding.
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 clearly states the tool searches shareholder behavior events, listing specific event types (减持/增持/回购/质押) and their English equivalents (share_reduction, share_increase, share_buyback, pledge_risk). It distinguishes this tool from sibling search tools like search_regulatory_events or search_dividend_events by focusing on insider signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a brief usage hint—'Use for insider signals'—but does not explicitly mention when not to use this tool or suggest alternatives. The sibling tool list implies alternatives, but the description lacks explicit guidance on selecting between similar search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint; description adds context about where shareholder name appears (structured_payload) and return format. Minor gap: no auth or rate limit info, but sufficient for the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, 4 sentences with front-loaded main action. No redundant information; each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage constraints, return structure, and pagination. Could mention edge cases or performance notes, but adequate for a search tool with good schema coverage.
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 baseline 3. Description adds value with example '罗丽华' and clarifies exact match, but doesn't significantly expand beyond schema definitions for cursor and limit.
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 clearly states the verb 'Query events by shareholder name' and specifies the resource. It distinguishes from siblings by mentioning when not to use it and suggesting alternatives like search_events_by_stock or search_events.
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 guidance on when to use (track specific shareholder activity) and when not to use (stock-level events or unsure name) is provided, with references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![astockevent-mcp MCP server](https://glama.ai/mcp/servers/NengjiangLunpi/astockevent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/NengjiangLunpi/astockevent-mcp)

Score Badge

Copy to your README.md:

[![astockevent-mcp MCP server](https://glama.ai/mcp/servers/NengjiangLunpi/astockevent-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NengjiangLunpi/astockevent-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NengjiangLunpi/astockevent-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server