Skip to main content
Glama
kevynf

AKBridge MCP Server

by kevynf

option_cffex_zz1000_spot_sina

Read-onlyIdempotent

Fetches real-time call and put option quotes for a specified CFFEX CSI 1000 index futures contract.

Instructions

中金所-中证 1000 指数-指定合约-实时行情 https://stock.finance.sina.com.cn/futures/view/optionsCffexDP.php :param symbol: 合约代码;用 option_cffex_zz1000_list_sina 函数查看 :type symbol: str :return: 中金所-中证 1000 指数-指定合约-看涨看跌实时行情 :rtype: pandas.DataFrame

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolNomo2208

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the agent knows this is a safe, repeatable read. The description adds that it returns both call and put realtime quotes as a DataFrame, which is useful, but no rate limits or freshness/latency characteristics are described.

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 purpose and constraint are front-loaded, and the source URL plus sphinx-style param/return lines are compact. There is minor boilerplate (URL, :rtype:) but nothing wasteful or padded.

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 single-parameter, read-only realtime quote tool with no output schema, the description covers purpose, parameter sourcing, and return type. It omits only format/timing details of the returned quotes, which is a minor gap against annotations that already carry the safety profile.

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% and the schema only supplies a default ('mo2208'), so the description does the compensating work: it explains that symbol is a contract code and points to option_cffex_zz1000_list_sina for valid values. That is meaningful added semantics beyond 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: real-time quotes (实时行情) for CFFEX CSI 1000 index options on a specified contract. It distinguishes itself from the daily and list siblings by naming the resource (spot vs daily) reasonably clearly, though it never explicitly contrasts with option_cffex_zz1000_daily_sina.

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?

It gives one actionable pointer: use option_cffex_zz1000_list_sina to obtain valid symbol codes. However, it offers no guidance on when to choose realtime spot over the daily counterpart, and no exclusions or prerequisites are stated.

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