Skip to main content
Glama
kevynf

AKBridge MCP Server

by kevynf

futures_spot_sys

Read-onlyIdempotent

Retrieves commodity spot-futures chart data for a specified futures symbol and indicator, returning market price, basis rate, or main basis as structured records.

Instructions

生意社-商品与期货-现期图 https://www.100ppi.com/sf/792.html :param symbol: 期货品种 :type symbol: str :param indicator: 市场价格;choice of {"市场价格", "基差率", "主力基差"} :type indicator: str :return: pandas.DataFrame :rtype: dict

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolNo铜
indicatorNo市场价格

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds the data source (生意社) and a return type, but the :return: pandas.DataFrame conflicts with the :rtype: dict, and no scoping, pagination, or freshness behavior is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loads the title, but it is raw numpy-style docstring boilerplate including a bare URL and a self-contradictory return-type pair, so not every line earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and only the return type named, the agent cannot tell what the call yields (dataframe rows, chart, one indicator series) or how indicator/ symbol interact. For a 2-parameter financial data tool this is under-specified.

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 0%, so the description must carry param meaning. It does document symbol as 期货品种 and, importantly, lists the three allowed indicator values (市场价格/基差率/主力基差) that the bare schema does not encode. However, it omits the default values (铜, 市场价格) present in the schema and gives no format details for symbol.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title/name combination indicates a 生意社 spot-vs-futures chart for a commodity, so the agent can infer the resource, but the description never states a clear verb or what is returned (chart image, time series, ratio). It does not distinguish itself from closely named siblings such as futures_spot_price, futures_spot_stock, or spot_price_qh.

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 guidance on when to use this tool versus the many sibling spot/futures tools, no prerequisites, and no exclusions. The only routing signal is the hardcoded source URL, which the agent cannot act on.

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