Skip to main content
Glama
Sign In
PandaStock

PandaStock

by D-Asce
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ChOneStockReal

Fetch a real-time quote for a single A-share stock (Shanghai, Shenzhen, or Beijing) using its 6-digit ticker code.

Instructions

获取单只股票实时行情。Get realtime quote for ONE stock. Args: code (str): 6-digit ticker, e.g. "600519" (贵州茅台 / Kweichow Moutai).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "ChOneStockReal"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.5

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full burden of behavioral disclosure, yet it says nothing about permissions, rate limits, data freshness/delay, or whether a missing ticker errors or returns empty. For a simple read-only quote fetch the risk is low, but the gap is real.

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?

Two short bilingual sentences with the identifier and the argument spec front-loaded; essentially no waste. The duplicated Chinese/English phrasing is slightly redundant but useful for matching either language.

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?

An output schema exists, so return values need not be explained, and the one parameter is fully described. The only shortfall is the absence of any scope or sibling-routing note for a very crowded tool family.

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% — the property is documented only as 'Code' — but the description compensates well by specifying the format (6-digit ticker) and giving a concrete example ('600519', Kweichow Moutai). The single parameter is fully usable without opening the schema.

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+resource: fetch a realtime quote for a single stock, emphasized by 'ONE'. It does not, however, differentiate itself from the close sibling ChStockCurReal, so an agent cannot tell the two apart from the description alone.

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?

There is no when-to-use guidance, no mention of alternatives (ChStockCurReal, ChMarketCurReal), and no statement of scope such as which exchanges or markets are covered. Usage must be inferred entirely from the name.

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