Skip to main content
Glama
kevynf

AKBridge MCP Server

by kevynf

option_cffex_zz1000_daily_sina

Read-onlyIdempotent

Fetch daily CFFEX CSI 1000 index option quotes for a specified contract symbol from Sina Finance. Use it to retrieve historical daily market data for call or put contracts.

Instructions

新浪财经-中金所-中证 1000 指数-指定合约-日频行情 :param symbol: 具体合约代码(包括看涨和看跌标识),可以通过 ak.option_cffex_zz1000_spot_sina 中的 call-标识 获取 :type symbol: str :return: 日频率数据 :rtype: pandas.DataFrame

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolNomo2208P6200

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the data source and return type (pandas.DataFrame), but does not disclose pagination, date-range behavior, or rate limits.

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 docstring is compact and front-loads the tool purpose before parameter details. It is appropriately sized for a single-parameter data retrieval tool, though the title-like opening repeats context already available in annotations.

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 simple one-parameter historical data tool with rich annotations and no output schema, the description covers source, purpose, parameter source, and return type. It could mention the time coverage of the daily data, but otherwise leaves no critical gap for correct invocation.

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

Parameters5/5

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

With schema description coverage at 0%, the description fully compensates by explaining that symbol is a specific contract code including call/put indicators and pointing to option_cffex_zz1000_spot_sina for obtaining it. This adds essential meaning beyond the bare schema default value.

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 names the source (新浪财经), exchange (中金所), underlying index (中证1000指数), contract specificity, and daily frequency, making it clear this retrieves daily option quotes. It distinguishes itself from the spot sibling by referencing option_cffex_zz1000_spot_sina only for symbol lookup, though it does not explicitly contrast with option_cffex_zz1000_list_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 useful guidance for obtaining the symbol from option_cffex_zz1000_spot_sina, which is more than no guidance. However, it does not state when to use this tool versus the list or spot siblings, leaving the broader usage context implicit.

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