Skip to main content
Glama
Sign In
a-share-mcp

a-share-mcp

by shouldnotappearcalm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_lhb_detail

Fetch Long-Hu-Bang (龙虎榜) detail data for stocks with notable institutional trading activity, filtered by date range and record count, and returned as Markdown, JSON, or CSV.

Instructions

    Fetches Long-Hu-Bang (龙虎榜) detail data.
    
    Long-Hu-Bang shows stocks with significant trading activity by institutional investors.
    Data source: Eastmoney via Akshare.

    Args:
        start_date: Start date in format 'YYYYMMDD'. Defaults to 3 days ago.
        end_date: End date in format 'YYYYMMDD'. Defaults to today.
        top_n: Number of records to return. Defaults to 20.
        format: Output format: 'markdown' | 'json' | 'csv'. Defaults to 'markdown'.

    Returns:
        Long-Hu-Bang data with: 代码, 名称, 上榜日期, 收盘价, 涨跌幅, 净买额, 买入额, 卖出额, 上榜原因, 解读

Input Schema

NameRequiredDescriptionDefault
top_nNo
formatNomarkdown
end_dateNo
start_dateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It discloses the data source, the meaning of the dataset, default values (3 days ago, today, 20 records) and the return fields, which is meaningful context, but it says nothing about ordering, pagination limits for large date ranges, throttling, or whether the call can be slow/empty on non-trading days.

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?

Purpose is front-loaded in the first line, followed by a brief explanation and a clearly labeled Args/Returns block. The Args section partly restates schema defaults, which is redundant given no annotations, but the structure is scannable with no filler prose.

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?

Although there is no output schema, the description enumerates the returned columns (代码, 名称, 上榜日期, 收盘价, 涨跌幅, 净买额, 买入额, 卖出额, 上榜原因, 解读), so an agent knows what it will get. Combined with parameter formats and defaults, nothing essential is missing for a four-parameter read-only data fetch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it largely does: all four parameters are documented with expected format ('YYYYMMDD'), defaults, and the format enum 'markdown' | 'json' | 'csv'. Minor gaps remain, e.g. whether top_n is applied after sorting by net buy amount or date, and whether a date range is inclusive.

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?

States a specific verb and resource ('Fetches Long-Hu-Bang (龙虎榜) detail data') and explains what Long-Hu-Bang represents, plus the data source (Eastmoney via Akshare). It does not explicitly distinguish itself from the sibling get_lhb_seats, so an agent must infer that this is the aggregate daily detail rather than the seat-level breakdown.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance is given; it never mentions get_lhb_seats or any other sibling as an alternative. The only contextual hint is that the data covers stocks with significant institutional trading activity, leaving routing decisions to inference.

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

Deploy Server

Other Tools