Skip to main content
Glama
kevynf

AKBridge MCP Server

by kevynf

news_economic_baidu

Read-onlyIdempotent

Retrieve economic data from Baidu Finance Calendar for a given date. Returns structured economic indicators as a DataFrame for analysis.

Instructions

百度股市通-经济数据 https://finance.baidu.com/calendar :param date: 查询日期 (格式:YYYYMMDD) :param cookie: cookie :return: 经济数据 pd.DataFrame

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo20251126
cookieNo

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 return type (pd.DataFrame), which is useful given no output schema, but says nothing about the auth/cookie requirement, rate limits, or pagination. Value beyond annotations is modest.

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 description is short and front-loads the source name, then the URL, then param notes. It is efficient with little filler, though the bare URL and the :param lines are raw docstring artifacts rather than polished agent-facing text.

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?

For a 2-param tool with no output schema, the description covers only the return type and date format. It omits what columns/content the DataFrame holds, the authentication story behind 'cookie', and any disambiguation from the large family of macro economic tools, so an agent lacks enough to select it confidently.

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

Parameters2/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 parameter meaning. It does explain the date format (YYYYMMDD), which is helpful, but 'cookie' is documented only as 'cookie' with no explanation of where to obtain it or how it is used, leaving one of two parameters effectively undocumented.

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 description identifies a source ('百度股市通-经济数据') and a URL, which implies an economic-calendar dataset. However, 'economic data' is broad and the description never states what the tool actually retrieves (events, indicators, calendar entries) or how it differs from the dozens of macro_* siblings that also return economic data. Purpose is inferable but not crisply defined.

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 and no alternatives named, despite the enormous sibling set (macro_china_cpi, macro_usa_cpi_monthly, etc.) competing for the same 'economic data' intent. The agent is left to guess whether this is a calendar, an aggregate feed, or a specific indicator source.

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