AkTools Pro MCP Server

by tchivs

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes and are grouped by asset class (stock, crypto, fund, futures, macro, pm). Some potential confusion exists between similar tools like stock_zt_pool_em and stock_zt_pool_strong_em, but descriptive suffixes and clear purposes keep boundaries mostly clear.
Naming Consistency4/5
The majority of tool names follow a consistent snake_case pattern with domain prefixes and descriptive suffixes (e.g., stock_indicators_a, futures_basis, macro_cpi). Minor inconsistencies like draw_ascii_chart vs draw_crypto_chart and backtest_strategy vs backtest_crypto_strategy, along with generic names like search, prevent a perfect score.
Tool Count2/5
58 tools is far beyond the 'too many' threshold (25+). Even for a broad financial data server, the sheer number is overwhelming and likely to increase selection difficulty for agents. The scope could be split into focused servers or reduced by consolidating overlapping utilities.
Completeness4/5
The toolset covers a wide range of financial domains (stocks, crypto, funds, futures, macro, FX, precious metals) and includes data retrieval, analysis, backtesting, and portfolio tracking. Minor gaps exist, such as no options data or detailed financial statements, but the surface is largely complete for its intended broad purpose.
Average 3.4/5 across 56 of 58 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does not state whether the tool is a read-only suggestion, a write/record operation, or how it communicates results. No side effects, permissions, or return behavior are mentioned, leaving the tool's actual execution opaque.
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 a single concise sentence that communicates its core purpose efficiently. It is front-loaded and avoids verbosity, though it omits important contextual details that would make it more useful.
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 no annotations, the description should explain what the tool returns and any behavioral nuances. It does not describe return values, side effects, or how the advice is delivered. For a 4-parameter tool, this is notably incomplete.
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 100%, and the schema already explains each parameter (symbol, action, score, reason) adequately. The description adds no additional meaning to the parameters, but the baseline of 3 applies because the schema does the heavy lifting.
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 states the tool 'gives specific investment advice based on AI analysis results of data from other tools,' which is a clear verb+resource. However, it does not distinguish itself from sibling tools like composite_stock_diagnostic or binance_ai_report that also generate advice, and the input schema (containing action, score, reason) suggests the tool may present pre-computed advice rather than generate it, creating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives. It merely describes what it does without mentioning prerequisites, exclusions, or when not to use it. The phrase 'based on AI analysis of other tools' hints at a sequence, but no explicit usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. The description contradicts the input schema by claiming the chart is based on a 'provided price list' when no such parameter exists; the actual inputs are market and symbol. This is a significant behavioral disclosure failure, as the agent cannot infer how data is obtained or what output to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It earns its place, though the content is problematic. Its brevity is a positive trait in itself.
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?
The tool is simple (2 scalar parameters, no output schema), but the description is incomplete. It fails to describe the output format or behavior, and the misleading 'price list' reference creates ambiguity. Without annotations or an output schema, the description should at least clarify how the tool operates, but it does not.
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 100% for both parameters (market and symbol), so the schema already documents the parameters adequately. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
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 clearly states the tool generates a simple ASCII trend chart and mentions the purpose of visually displaying trends. However, it refers to a 'provided price list' while the input schema expects a market and symbol, which is somewhat misleading. It somewhat distinguishes from the sibling draw_crypto_chart by name, but not explicitly in the description.
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?
The description provides no guidance on when to use this tool versus alternatives like draw_crypto_chart. It does not mention supported markets, exclusions (e.g., crypto), or typical use cases. Usage context is only implied by the schema's market parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says '获取报告' (get report) without mentioning any side effects, output format, data source specifics, or limitations. This is minimal for a tool that returns an analysis report.
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?
The description is short, but the second sentence ('此工具对分析加密货币非常有用，推荐使用') is subjective filler that doesn't add functional information. The first sentence earns its place, but the second is unnecessary.
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?
The tool has no output schema and no annotations, yet the description does not explain what the report contains or how the agent should use it. The single parameter is documented, but overall the description is insufficient to fully inform an agent about expected return values or context.
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?
The schema description for 'symbol' is clear ('加密货币币种，格式: BTC 或 ETH'), providing 100% coverage. The tool description itself adds no additional parameter meaning, so the baseline 3 is appropriate.
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 clearly states the tool fetches Binance's AI analysis report on cryptocurrencies, using the specific verb '获取' (get/fetch) and identifying the resource and scope. It is distinct from sibling crypto tools like crypto_prices or crypto_sentiment_metrics, though it doesn't explicitly compare to them.
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?
The only usage guidance is '此工具对分析加密货币非常有用，推荐使用' (this tool is very useful for analyzing cryptocurrencies, recommended to use), which is a vague recommendation rather than specific when-to-use or when-not-to-use guidance. It does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions 'composite skill' and 'one-click access', implying a read operation, but does not disclose output format, potential delays, side effects, or any requirements. Minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with '复合技能' (composite skill), and contains no fluff. It is extremely concise and well-structured for the amount of content it provides.
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?
The tool is a composite diagnostic with potentially complex output, but there is no output schema and no annotations. The description gives only a high-level summary of data categories, not enough for an agent to anticipate the response structure or handle edge cases like unsupported markets. Inadequate for the tool's complexity.
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?
The schema fully describes both parameters (market with supported values and symbol meaning), so the baseline is 3. The description adds no additional parameter semantics, but the schema coverage is complete enough.
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 clearly states it provides comprehensive diagnostic data covering technical, fundamental, and news aspects, using a specific verb '获取' and resource. It distinguishes itself from single-aspect sibling tools like stock_indicators or stock_news, though it does not explicitly mention individual stock scope beyond the title.
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 alternatives. It implies a one-click comprehensive access but does not name any alternatives, state prerequisites, or explain when this should be preferred over calling individual indicator or news tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of disclosure. It only states that real-time signals are scanned, but fails to disclose return format, whether the optional 'symbol' parameter filters results, or any limitations. This is insufficient for a read-only data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action (扫描) and scope (A股市场实时异动信号). It is concise with no filler or redundant content, earning a perfect score for efficiency.
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?
Given no output schema and no annotations, the description is incomplete. It does not mention that the parameter can filter by anomaly type, nor does it hint at the response structure (e.g., list of signals, timestamps, severity). This leaves significant gaps for an agent to correctly invoke and interpret the tool.
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?
The schema already provides 100% coverage with a detailed description of the 'symbol' parameter listing all 8 anomaly types. The description adds only redundant examples and does not clarify the misleading parameter name 'symbol' (which actually denotes anomaly type), so it adds no significant meaning 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?
The description clearly states the tool scans real-time A-share market anomaly signals with specific examples like '火箭发射' and '大笔买入'. It uses a specific verb (扫描) and resource (A股市场实时的异动信号), but does not explicitly differentiate from sibling tools such as stock_zt_pool_em that also track market extremes.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or related tools that might be more appropriate for specific scenarios, such as using stock_zt_pool_em for limit-up pools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only notes 'standardized output fields' but does not mention rate limits, pagination behavior, or limitations (e.g., weekly period not supported for US stocks). This is insufficient for a tool that likely fetches external data.
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 a single concise sentence with a clear front-loaded verb. It wastes no words, but could be considered too sparse given the tool's complexity. It lacks structured detail, but it is appropriately sized for a simple read tool, earning a 4.
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?
Given the complexity (5 params) and the existence of many sibling tools, the description is incomplete. It fails to clarify how it relates to stock_indicators_* tools, lacks usage guidance, and provides no behavioral context (e.g., limitations, default behavior). The output schema exists, but no return values need explaining.
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?
The schema provides descriptions for all 5 parameters (100% coverage), so the baseline is 3. The description adds minimal value beyond the schema, only implying that the tool returns both prices and indicators, which is not explicitly stated in any parameter description.
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 clearly states the tool retrieves historical prices and technical indicators for stocks and ETFs, with a specific verb ('获取') and resource. However, it does not distinguish itself from sibling tools like stock_indicators_a/hk/us, which likely overlap in offering technical indicators.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention exclusions (e.g., not for crypto) or point to sibling tools for other asset classes. Schema constraints (like market limitations) are in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无任何 annotations，描述需承担全部行为披露责任。虽然说明了返回数据包含价格走势和技术指标，但未提及数据频率、limit 参数的作用、分页行为、是否只读等边界或副作用信息，agent 难以预知调用行为。
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?
描述为单句，信息密度较高，没有冗余或空话。不过'等品种'和'技术指标'表述较模糊，可进一步明确具体范围，但整体结构仍简洁高效。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具为简单查询型，参数完整，但无输出 schema。描述说明了数据内容和范围，未说明 limit 如何影响返回、数据的时间跨度、是否包含实时数据等。在无标注、无输出 schema 的情况下，描述仍有明显缺口，但工具定位尚清晰。
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 对两个参数均提供了完整描述（limit 默认30并建议30-252，symbol 枚举所有支持的品种），schema 覆盖率为100%。描述本身未额外增加参数语义，仅重复提到黄金白银，因此维持基准3分。
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?
描述以动词'获取'明确指向上海黄金交易所现货历史价格数据，并具体提及黄金、白银等品种和价格走势、技术指标，能将其与 pm_international_prices、pm_benchmark_price 等兄弟工具区分开来。虽未明说排除其他工具，但资源定位已经足够清晰。
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?
描述未提供任何使用时机或与替代工具的对照说明，未告知何时应用本工具而非 pm_international_prices 或 pm_benchmark_price。仅隐含'现货历史'这一语境，缺乏明确的 when/when-not 指导。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It claims to return 'all' limit-up stocks, but the limit parameter (default 50, range 30-100) contradicts this, indicating a cap on results. The description does not disclose this limitation, nor any other behavioral details like rate limits or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that immediately states the tool's purpose with no filler words. It is well structured and front-loaded.
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?
Given the lack of an output schema and annotations, the description should explain what data is returned (e.g., stock codes, names, statistics) and clarify the limit cap. It fails to do so, making the description incomplete for a tool that returns a data pool.
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?
Both parameters are already fully described in the schema (date format and limit range/default), giving 100% schema coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 uses the specific verb '获取' (get) and identifies the resource as all limit-up stocks in China's A-share market (Shanghai, Shenzhen), clearly stating the tool's function. However, it does not distinguish itself from the sibling tool stock_zt_pool_strong_em, which likely serves a similar purpose.
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 alternatives. The description does not mention any conditions, exclusions, or prerequisites, and the optional date/limit parameters are only documented in the schema, not in usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'get data', which implies a read operation, but it does not disclose any return format, additional behavior, or limitations. It offers minimal insight beyond what the tool name already suggests, failing to provide meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the tool's purpose without any fluff or redundancy. It is appropriately sized for a simple data retrieval tool and front-loaded with the key action and target. Every word 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?
While the tool has only two parameters and no output schema, the description is notably incomplete. It does not define what constitutes a 'strong stock pool', nor does it explain how this tool relates to the similarly named stock_zt_pool_em. Without this context, an agent cannot judge when to use this tool or what to expect from the results, leaving a significant gap despite the tool's seeming simplicity.
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 100% for both parameters, so the baseline is 3. The tool description itself adds no information about parameters; it merely names the resource. The schema already explains the date format, default behavior, and limit range, so the description does not need to compensate. This is an acceptable passing score for coverage.
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 clearly states it retrieves Chinese A-share market strong stock pool data with a specific verb ('获取') and resource ('强势股池数据'). It is clear and specific, but it does not explicitly distinguish itself from the sibling tool stock_zt_pool_em, which appears to be a related but different pool (regular limit-up pool vs strong pool). Thus it meets the 'clear but no sibling differentiation' criterion.
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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of when to prefer 'strong stock pool' over the regular limit-up pool or other stock data tools. The name implies distinction, but the description itself gives no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that keys can be cleared but does not mention side effects, irreversibility, or potential performance impact after clearing. For a destructive operation, this is a significant transparency gap.
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 extremely concise, using two short phrases to communicate the core behavior. It is well front-loaded, though it could include a bit more structure around usage without sacrificing brevity.
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?
Given that this is a destructive tool with no annotations, no output schema, and only one parameter, the description still lacks essential context about side effects and when to invoke it. The simple structure does not compensate for the missing behavioral and usage details.
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?
The schema description fully covers the single parameter 'key', including the default behavior when left empty. The description simply repeats the same semantics without adding extra detail or clarification, so it does not exceed the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('clear') and resource ('cache'), specifying two modes: clearing a specific key or all cache. This distinguishes it from the sibling tool cache_status, which is about viewing cache state.
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?
The description provides no explicit guidance on when to use this tool versus alternatives like cache_status. It does not mention prerequisites, typical scenarios, or when clearing all cache might be preferred over a specific key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions generating an ASCII chart and does not reveal whether it fetches live market data, the data source, potential errors, or the format of the output beyond being an ASCII chart. This is minimal transparency.
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 a single, focused sentence with no redundant words. It efficiently communicates the core purpose. Though it could be more informative, the structure is appropriately concise and front-loaded.
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?
The tool lacks annotations and an output schema, so the description must compensate. It does not clarify how it differs from the similar draw_ascii_chart tool, nor does it explain data source, update frequency, or error behavior. Given the simplicity of the tool, the description is still insufficiently complete for correct invocation without further context.
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?
The input schema already provides 100% description coverage for both parameters (bar and symbol), so the baseline is 3. The description does not add any additional meaning or context for the parameters beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates ASCII trend charts for cryptocurrencies, with the explicit verb '生成' (generate) and resource '加密货币的 ASCII 走势图' (crypto ASCII trend chart). This distinguishes it from the broader draw_ascii_chart sibling and other crypto price tools.
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?
No guidance is provided about when to use this tool versus alternatives. It does not mention that draw_ascii_chart is for generic charts or that crypto_prices provides price data instead. The description only states what the tool does, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only query by using '获取' (get) and adds a temporal qualifier '最新' (latest), but does not disclose the return format, data source, limitations, or any other behavioral traits. The description is minimal and leaves transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and subject. It contains no superfluous information and reads naturally, earning full marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description provides a basic understanding of the tool's function. However, it is vague about the exact contents of the returned data ('等信息' = 'and other information'), leaving questions about which specific institutional holdings and ratios are included. It is minimally viable but lacks full completeness.
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?
The schema already fully documents the single parameter 'symbol' with description '股票代码' (stock code), achieving 100% schema coverage. The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
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 clearly states the tool retrieves the latest institutional holdings and shareholding ratios for individual stocks, using a specific verb ('获取') and resource ('个股最新机构持仓与持股比例'). It effectively conveys the tool's scope, though it does not explicitly differentiate itself from sibling tools like fund_holdings or stock_info.
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?
The description provides no guidance on when to use this tool versus alternatives. It only states what the tool does, without mentioning any prerequisites, excluded use cases, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses a read operation ('获取') but does not describe output structure, data source, or any side effects. Additionally, the description says '行业' (industry) while the schema allows multiple category types, which is a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core function with no unnecessary words. It is appropriately sized and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no output schema, no annotations), the description provides the essential purpose but falls short by not mentioning the ranking behavior (from the name) or the broader category support in the schema. It is minimally viable but lacks full contextual richness.
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 100%, with both parameters (cate and days) having detailed descriptions of allowed values. The tool description does not add any extra parameter semantics beyond what the schema already provides, so it stays at the baseline.
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 clearly states a specific action ('获取' / get) and target ('中国A股市场的行业资金流向数据' / China A-share market industry capital flow data), which aligns with the tool's name and title. However, it does not mention the 'rank' aspect or distinguish this tool from sibling sector-related tools like sector_rotation or sector_valuation. It also narrows the scope to '行业' (industry) while the schema supports '概念' and '地域' categories.
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?
The description provides no guidance on when to use this tool versus alternatives. The schema's parameter description for 'days' includes a caution about trading days, but the main description offers no contextual decision support or comparisons with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'simple strategy backtesting' without mentioning side effects, data caching, rate limits, or whether the operation is read-only. The tool likely performs a read-only computation, but this is not stated, leaving the agent uncertain about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose ('simple strategy backtesting') and includes the key supported strategies. No unnecessary words or repetition.
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?
The tool has no output schema and no annotations, so the description should explain what the backtest returns or any prerequisites. It only states the action and strategy types, without indicating outcome format, performance metrics, or execution behavior. For a multi-parameter tool, this is incomplete.
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?
The input schema already provides 100% description coverage for all parameters, including the list of strategies. The description's parenthetical strategy list adds no additional meaning beyond what the schema already conveys. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs simple strategy backtesting based on historical prices and technical indicators, listing supported strategies (SMA/RSI/MACD/BOLL/MA_CROSS/KDJ). This distinguishes it from the sibling backtest_crypto_strategy by focusing on stock-style strategies and not mentioning crypto.
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?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention the sibling backtest_crypto_strategy or exclusions like 'use for stocks only'. While the market parameter schema notes 'no crypto', this is not in the description, leaving usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose whether the operation is read-only, any rate limits, response format, or other behavior. The description only restates the basic action without adding beyond-obvious detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, low-complexity tool, the description is minimally viable: the agent can infer that calling it returns current global financial news. However, there is no output schema and the description does not specify the returned data structure, fields, or source, leaving the agent uncertain about the response form.
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?
The tool has zero parameters, so the description cannot add parameter-level meaning. The input schema is already complete with no properties, and the baseline for zero parameters is 4.
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 uses a specific verb ('获取' - get) and resource ('全球财经快讯' - global financial news), clarifying that this tool returns the latest global financial news. It does not explicitly contrast with sibling tool stock_news, though the 'global' qualifier partially differentiates it.
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?
No guidance is provided about when to choose this tool over alternatives like stock_news or market_prices. There is no mention of scenarios, exclusions, or recommended use cases, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'standardized market fields' but does not disclose limitations, data availability, rate limits, or return format details. The behavioral traits are minimally revealed beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, tightly packed with essential information and no fluff. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with well-documented parameters, the description is reasonably complete. However, it lacks usage context and does not clarify the output schema format, which could be valuable given the many sibling tools. The missing behavioral and usage details keep it from being more complete.
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?
The input schema provides full descriptions for all three parameters, including defaults and allowed values. The description adds no extra parameter context, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves OKX cryptocurrency historical K-line data and outputs standardized market fields. The specific verb (获取) and resource (OKX historical K-line) distinguish it from sibling tools like crypto_sentiment_metrics or market_prices.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for historical data, how it differs from real-time market prices, or any selection criteria relative to other crypto tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the basic purpose and does not mention data sources, update frequency, default parameter behavior, error handling, or any side effects. The description adds little beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's function and key output fields. It contains no unnecessary words or redundancy, making it an efficient and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description gives a reasonable overview of the expected output. However, it lacks details about the return format and does not contextualize the tool among the many fund-related siblings, leaving some ambiguity about the exact scope of '详细信息'.
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?
The input schema fully documents the single 'code' parameter with a description and example, achieving 100% schema description coverage. The tool description does not add any parameter-specific semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb '获取' (get) and resource '基金基本信息' (fund basic information), and lists concrete fields (name, type, scale, manager). This distinguishes it from sibling tools like fund_nav, fund_holdings, and fund_ranking, which cover different aspects of fund data.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or comparison with sibling fund tools, leaving the agent without contextual cues for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'output standardized fields' but does not specify what those fields are, whether any authentication is needed, or if there are rate limits. It is a read-only operation by nature, but that is not explicitly stated, and the vague 'standardized fields' leaves much unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and output in a compact manner. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is adequate but not complete. There is no output schema, so the description's phrase 'standardized fields' is insufficient to inform the agent about the return structure. It also lacks usage guidance relative to fx_history. However, the tool is simple, and no nested objects or complex behaviors are involved, so a moderate score is appropriate.
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?
The input schema fully describes the single 'symbol' parameter, listing all supported currency pairs with 100% coverage. The description adds no parameter-specific detail beyond what the schema already provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving real-time exchange rates for major currency pairs and outputting standardized fields. It distinguishes itself from sibling fx_history by explicitly saying '实时' (real-time), and from crypto/futures tools by its focus on FX.
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?
No guidance is provided on when to use this tool versus alternatives. Although the 'real-time' wording implies it is for current rates, there is no explicit mention of fx_history for historical data or any other exclusions. The description does not help an agent choose between fx_rates and the closely related fx_history sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention return format, potential errors, data source, or any side effects. This is a minimal disclosure that only states the basic purpose, which is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant content. It is front-loaded with the primary verb and resource, making it easy for an agent to quickly understand the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter and no output schema, but the description is brief and does not specify which key indicators are included or what the response structure looks like. While adequate for a simple fetch, it leaves some gaps that could hinder an agent's ability to fully anticipate the tool's behavior.
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?
The schema description coverage is 100% (the 'symbol' parameter has a description '股票代码'), and the tool description adds no additional semantic meaning to the parameter. Per the baseline rule, a score of 3 is appropriate when the schema already covers parameter meaning.
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 clearly states that the tool retrieves key financial report indicators for Hong Kong stocks, using a specific verb ('获取') and a specific resource ('港股市场的股票财务报告关键指标'). It distinguishes itself from sibling tools like stock_indicators_a and stock_indicators_us by explicitly mentioning the HK market, though it doesn't explicitly contrast with them.
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?
The usage context is implied: the tool is for HK stocks, and given sibling tool names (stock_indicators_a, stock_indicators_us), an agent can infer when to use this tool. However, there is no explicit guidance on when to use it versus alternatives or any exclusions, leaving the differentiation largely to the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It discloses input constraints (symbol and market) and the no-crypto limitation, but does not describe the return format, error behavior, data scope, or any side effects. This is a minimal disclosure for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the main purpose and the key exclusion. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema, the description is acceptable but not rich. It covers the core function and the crypto exclusion, but lacks usage guidance relative to siblings and leaves 'basic info' undefined. Overall it is minimally complete given the low complexity.
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?
The input schema fully describes both parameters, including the supported market values and the no-crypto restriction. The description adds no parameter information beyond what the schema already provides, so the baseline score of 3 applies.
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 clearly states the tool retrieves basic stock information using a stock code and market, and explicitly notes that cryptocurrency is not supported. It identifies the action and resource, but 'basic information' remains somewhat vague and it does not strongly distinguish itself from sibling stock tools like stock_indicators_* or market_prices.
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?
The description implies usage for stock information lookup and explicitly excludes cryptocurrency, which serves as a limited usage constraint. However, it does not mention any sibling alternatives or provide guidance on when to prefer this tool over other stock-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the core purpose and does not mention read-only nature, data source (Sina, only in tool name), rate limits, pagination, or return format. The schema covers the '仅支持' constraint for days, but the description adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no filler. It front-loads the action and resource, being appropriately concise for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (two fully-documented optional parameters), the absence of an output schema means the description should explain return values. It does not, leaving a gap. However, the core purpose is clear enough for basic usage, making it minimally viable.
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 100%, with both days and limit having descriptions. The tool description adds no parameter-specific meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and the specific resource: 龙虎榜个股上榜统计数据 (Dragon-Tiger List individual stock statistics) for A-shares in Shanghai and Shenzhen. This differentiates from sibling tools like stock_zt_pool_em (limit-up pool) and northbound_funds.
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?
No guidance is given on when to use this tool versus alternatives such as stock_zt_pool_em or stock_sector_fund_flow_rank. There are no exclusions, prerequisites, or recommended scenarios described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that recent news is fetched, with no disclosure of return format, pagination, rate limits, or side effects. The behavior is implied to be read-only but not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the tool's function. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is present but minimal. It does not explain what the returned news contains (e.g., article titles, timestamps, links), which might be useful, but the schema covers parameters and the tool's simplicity mitigates the gap.
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?
The input schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional meaning beyond what the schema already provides; limit is described as '返回数量' in the schema, and symbol is just '股票代码'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (获取/get) and the target (指定个股最近新闻动态/recent news for a specified stock), with the scope '指定个股' distinguishing it from the global news sibling tool stock_news_global. This is a specific and unambiguous purpose.
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 alternatives. The description only states the basic function without mentioning exclusions, prerequisites, or alternative tools such as stock_news_global.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'one-click obtain' without disclosing whether the tool is read-only, whether it calls multiple backend services, or any potential latency. It does not detail what side effects or limitations might exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the composite nature and the three component areas. It is concise with no unnecessary words or repetition.
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 minimal behavioral details, the description leaves the response structure unspecified. It lists the data categories but does not explain how they are organized or returned, which is insufficient for a composite diagnostic tool.
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?
The input schema already fully describes the single 'symbol' parameter with format guidance and a default value. The description adds no extra semantic nuance beyond the term 'crypto', so it meets the baseline given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a composite skill that fetches comprehensive diagnostic data across technical analysis, sentiment, and AI reports. This specific verb+resource combination distinguishes it from sibling tools that focus on only one of these aspects.
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?
The description implies usage when a one-click combined view is wanted, but it does not explicitly state when to use this tool versus calling crypto_sentiment_metrics, binance_ai_report, or other separate tools. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does indicate a read-only operation ('获取') and names the data content, which conveys the basic behavior. However, it lacks details on response format, data granularity scope, or any rate limits/pagination, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. It is concise, with no extraneous words or repetition of schema details.
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?
The tool has 3 optional parameters, no output schema, and no annotations. The description identifies the data types but does not explain the return structure, typical use cases, or how it complements other sentiment/crypto tools. For an agent to invoke and interpret results autonomously, this is insufficient context.
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 100%, with each parameter (period, symbol, inst_type) having its own description. The tool description adds no additional parameter semantic information beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取OKX加密货币杠杆多空比与主动买卖数据', clearly specifying the action (get), data source (OKX), and data types (leverage long/short ratio and active buy/sell). This distinguishes it from sibling sentiment tools like fear_greed_index or crypto_prices.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, preferred contexts, or comparisons to siblings. The agent is left without decision criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It claims support for time period filtering that is not present in the input schema, and it does not disclose output format or other behavioral details. This internal inconsistency reduces transparency.
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 a single, concise sentence and is front-loaded. However, the mention of time period filtering is inaccurate and does not earn its place, slightly reducing the score from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no annotations, no output schema). The description gives a basic idea of what it does and mentions indicators like yield and scale, but it omits return format and leaves the temporal filtering discrepancy unresolved, making it incomplete for an agent to fully rely on.
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?
The schema provides 100% coverage for the only parameter 'type' with a description listing allowed values, so the baseline is 3. The description does not add new meaning to the parameter itself and introduces an unsupported time period attribute.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool '获取不同类型基金的排行榜数据' (gets ranking data for different types of funds), using a specific verb and resource. It distinguishes from sibling fund tools like fund_info, fund_nav, and fund_holdings by focusing on rankings.
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?
The usage context is implied (for retrieving fund rankings), but no explicit alternatives or exclusions are provided. The mention of filtering by time period is unsupported by the schema, creating potential confusion about how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It only states the tool 'gets' data, implying a read-only operation, but it offers no additional behavioral context such as data coverage (e.g., historical vs current), update frequency, or any limitations. This is minimal disclosure beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with clear structure: verb, resource, and purpose. No redundant words.
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?
Given there is no output schema and no annotations, the description should explain what the returned basis data looks like (e.g., timeframe, unit, series) and when to use it. It lacks these details, leaving the agent with only the assurance that some basis data is returned. Completeness is therefore limited.
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?
The input schema fully documents the single 'symbol' parameter with a default value and a comprehensive list of supported varieties. The description adds no parameter-specific detail, so it adds no value beyond the schema; baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves basis data between futures and spot prices, with the purpose of assessing market expectations and arbitrage opportunities. This distinguishes it from sibling tools like futures_prices which handle absolute prices.
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?
The description implies usage for basis analysis (market expectations, arbitrage) but gives no explicit when/when-not guidance or references to alternative tools. The intended context is clear but not formally differentiated from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose operational details. It only states the data source and metal types, but omits the response format, units, data frequency, pagination behavior, or any side effects. This is insufficient for the agent to fully anticipate the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's core function without any redundant phrases. It is front-loaded and every word contributes.
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?
Given the absence of an output schema and annotations, the description should explain what the returned inventory data represents (e.g., historical series, current stock levels) and how the output is structured. It only provides a high-level purpose, making it incomplete for a data retrieval tool.
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?
The input schema already describes both parameters with 100% coverage, including suggested range for limit and supported values for metal. The description adds no additional parameter details beyond referencing gold/silver, so it meets the baseline without adding extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves COMEX exchange gold or silver inventory data ('获取COMEX交易所黄金或白银库存数据'), specifying a concrete verb and resource. It is distinguished from sibling tools like pm_spot_prices and futures_inventory by naming the exact exchange and metal scope.
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?
The description mentions the use case '用于判断供需关系' (to assess supply-demand), providing some context, but it does not explicitly state when to use this tool over alternatives such as pm_basis or futures_inventory, nor does it mention exclusions. Thus usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions '模拟盘' (simulated market) but does not disclose side effects, idempotency, validation rules, required permissions, or return behavior, which is significant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy or filler. It front-loads the action and resource, making it highly concise and easy to parse.
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?
Despite having 4 parameters and no output schema, the description does not explain return values, parameter relationships, or how the tool integrates with the portfolio system. It is minimal and leaves many operational details unstated.
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 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides; it only notes the tool's overall purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action ('添加', add) and resource ('持仓记录', holding record) within a simulated market context, clearly distinguishing it from sibling read-only tools like portfolio_view and portfolio_chart.
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?
The phrase '在模拟盘中' and '用于后续跟踪盈亏' imply usage context (simulated trading, P&L tracking), but the description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the disclosure burden. It adds useful context by specifying '国内' and '主力合约', which limits scope and clarifies the type of data returned. However, it does not describe output format, data ordering, or potential errors, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the purpose and key data fields. It is appropriately concise with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and absence of an output schema, the description provides enough to understand the basic functionality and data types, but lacks details about return structure, limit behavior, or how to handle invalid symbols. It is adequate but not fully complete.
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?
The input schema describes both parameters (symbol and limit) with 100% coverage, including an enumerated list of supported symbols. The description adds no extra parameter semantics beyond the schema, meeting the baseline for high schema coverage.
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 clearly states the tool retrieves historical price data for domestic futures main contracts, including OHLCV and volume. The verb '获取' pairs with a specific resource, and the inclusion of '主力合约' distinguishes it from futures inventory/basis tools, though it does not explicitly name sibling alternatives.
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?
Usage is implied: the description implies this tool is for historical futures price data, but there is no explicit guidance on when to prefer it over futures_inventory, futures_basis, or others. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states that historical data is retrieved; it does not mention ordering, time range, data source, or response format. This adds little beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose and includes a relevant use case. Every word earns its place; there is no redundancy or clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description communicates the core function adequately, but it lacks explicit guidance on when to use it versus fx_rates and does not describe the return structure. Given the absence of annotations and an output schema, this is minimally complete but has clear gaps.
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?
The input schema covers 100% of parameters with descriptions for both 'limit' and 'symbol', including supported currency pair codes. The description adds no additional meaning to the parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '获取' and clearly identifies the resource as '历史汇率数据' for a specified currency pair. The word '历史' distinguishes it from sibling fx_rates, which presumably provides current rates, and the stated purpose of analyzing trends and volatility adds context.
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?
The description implies usage for historical exchange rate analysis ('用于分析汇率走势和波动') but does not explicitly mention alternatives like fx_rates or state when not to use this tool. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only lists the data fields returned and does not mention response format, pagination, rate limits, or any other behavioral traits. For a read-only data retrieval tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the tool's core functionality without any fluff or repetition. It uses precise terminology and is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only one optional parameter and no output schema, the description sufficiently covers what data the tool returns. However, it could be more complete by noting the frequency (quarterly) is already mentioned, but it lacks details about the time range or how the limit affects the output, leaving some ambiguity for the agent.
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?
The input schema has a single parameter 'limit' with a clear description and default value, covering 100% of parameters. The description does not add extra meaning about the parameter, but the schema already provides sufficient semantics, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool fetches China's quarterly GDP data, specifying the key indicators (quarterly value, YoY growth, QoQ growth). This distinguishes it from sibling macro tools like macro_cpi and macro_pmi, which fetch different economic indicators.
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?
The description implies usage when GDP data is needed, but it does not explicitly mention alternatives or when not to use the tool. Given the sibling context, the purpose alone provides some guidance, but no direct comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description is the sole source of behavioral information. It states the data fetch and time range but does not disclose return format, potential delays, or whether the operation is strictly read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the resource and time range. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description leaves undefined what fields or structure the returned data has. However, the tool's simplicity and clear time scope partially compensate. More detail on the returned data would improve completeness.
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?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter semantics, but with no parameters, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '获取' (get/fetch) and names the resource '北向资金' (northbound funds) with a clear time scope of the last 10 trading days. This distinguishes it from sibling tools like institutional_holding_summary or market_prices.
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?
No guidance is provided on when to use this tool instead of alternatives, nor any exclusions or prerequisites. The description only states what the tool does, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says it gets data, which is an obvious read operation, but does not disclose any limitations, data freshness, authentication needs, or output characteristics. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the core function and a use case with no redundant or filler content. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple with one parameter and no annotations, so the description is moderately complete. However, it lacks any detail about the return structure or potential limitations (e.g., supported symbols, time range), which is important since no output schema exists to fill the gap.
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?
The input schema has a single parameter 'symbol' with a description, giving 100% schema description coverage. The tool description adds no information about parameters, so the baseline of 3 applies. No additional meaning is conveyed 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?
The description clearly states it retrieves open interest data for OKX perpetual contracts, which is a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like okx_funding_rate, though the unique focus on open interest provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('用于判断市场资金流向' – to judge market capital flow direction), giving context on when to use it. However, it does not state when not to use it or mention alternative tools, so excluded explicit exclusions keep it at a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It identifies the source (SGE) and the type (benchmark), but fails to mention behavioral details such as the historical nature of the data implied by the 'limit' parameter, update frequency, or return characteristics. The tool's safe read-only behavior is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately communicating the core action and resource. There is no redundant information, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple price retrieval tool with a rich schema, this description is adequate but not complete. It lacks positioning among the many precious metals sibling tools (e.g., why use this vs. pm_international_prices), and does not clarify the role of the 'limit' parameter in returning historical benchmark prices.
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 100%, with both 'limit' and 'metal' fully described. The tool description merely mentions gold/silver, adding no new semantics beyond the schema. The baseline of 3 applies because the schema handles parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' - retrieve) and a specific resource: the gold or silver benchmark price published by the Shanghai Gold Exchange. This distinguishes it from sibling tools like pm_spot_prices or pm_international_prices, which target different price types or markets.
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?
The phrase '这是国内贵金属定价的重要参考' implies a use case (domestic precious metals pricing reference), but it does not explicitly mention alternatives or when-not-to-use. It offers only implicit guidance, with no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'calculates' P/L but does not mention that it is read-only, whether it requires existing positions, what data source is used, or how often it updates. The behavioral traits are not disclosed beyond the basic computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's function with no filler or redundancy. It is front-loaded and every word contributes to the meaning, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero params, no output schema), so the description does not need to cover complex inputs or return formats. However, it does not specify what the output looks like (e.g., total P/L, per-position breakdown, or currency), which is a gap for an agent needing to interpret the tool's result in a workflow.
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?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings, and the schema already covers all (none) parameters. There is no ambiguity or missing parameter context to penalize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '计算当前所有模拟持仓的实时盈亏情况' (calculates real-time P/L of all current simulated positions), providing a specific verb, resource, and scope. This distinguishes it from sibling tools like portfolio_add (adding positions) and portfolio_chart (charting), so the purpose is unambiguous.
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?
The description implies usage (viewing portfolio P/L) but provides no explicit guidance on when to use this tool versus alternatives such as portfolio_chart or portfolio_add. It lacks any 'when not to use' or comparison to sibling tools, leaving the selection partly to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the basic function and market scope, without mentioning data source, update frequency, potential limitations, or any other behavioral characteristics. The description adds minimal context beyond the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the essential information: what the tool does and its market scope. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description is fairly simple. However, it does not clarify what 'key indicators' are included, which could be important for an agent deciding whether to use this tool. The absence of an output schema increases the need for such detail, making the description only minimally viable.
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 100% because the 'symbol' parameter has the description '股票代码' (stock code). The tool description adds no additional parameter semantics beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '获取' (retrieve) and a clear resource '股票财务报告关键指标' (key financial report indicators). It explicitly scopes to China's A-share market (Shanghai, Shenzhen), which distinguishes it from sibling tools like stock_indicators_hk and stock_indicators_us. The purpose is unambiguous.
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?
The description implies usage for A-share stocks by specifying the market, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No alternative tools are referenced. Usage is inferred rather than articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects, return format, data source, or limitations. The term 'simple' hints at limited scope but provides no concrete behavioral details such as whether it places real orders or only simulates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the main action, and no filler words. It is appropriately concise for a simple tool description.
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 no behavioral info in the description, it is insufficient for an agent to understand what the backtest returns or the tool's limitations. It lacks details on result format, time period, or any caveats.
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 coverage is 100%, with each parameter having descriptions and defaults. The tool description reiterates strategy options (SMA/RSI/MACD) already present in the schema, adding minimal value. Baseline of 3 is appropriate due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: conducting simple strategy backtesting on crypto historical prices with technical indicators (SMA/RSI/MACD). The verb '回测' (backtest) and resource 'crypto' distinguish it from sibling tools like backtest_strategy (presumably for stocks) and other crypto data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for crypto strategy backtesting and provides clear context via the mention of crypto and specific indicators. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear that an agent would know to use this for crypto backtesting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the meaning of positive/negative funding rates, adding domain context, but does not disclose response format, real-time vs. historical nature, rate limits, or error behavior. This leaves room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose and adds a valuable interpretation of the sign. Every word earns its place, with no filler.
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?
This is a low-complexity tool with one optional parameter and no output schema. The description clearly identifies the resource and explains the sign semantics, which is largely sufficient. However, it does not explicitly mention the return value structure or the time period of the rate, leaving minor ambiguity.
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?
The schema provides 100% coverage for the single 'symbol' parameter, including a default and format guidance. The tool description adds no extra parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '获取' (get) with the resource 'OKX永续合约的资金费率' (OKX perpetual contract funding rate), clearly distinguishing it from sibling tools like okx_open_interest. It also adds interpretive context about positive/negative rates, making the purpose explicit.
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?
No guidance is provided on when to use this tool versus alternatives such as okx_open_interest or crypto_prices. There are no exclusions, prerequisites, or context cues to help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description shoulders the transparency burden. It discloses the analytic approach (fund flow + price change) and the short-term focus, but omits output format, data source, or update cadence. This is moderate transparency, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and key context. Every word is informative, with no fluff or repetition, making it ideal for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain return values, but it doesn't. However, the core purpose is clear enough for basic selection. For a simple no-param read tool, this is adequate but not comprehensive.
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?
The tool has zero parameters, so the input schema trivially covers all cases. Baseline 4 is appropriate since there is nothing for the description to add about parameters.
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 clearly states the tool identifies short-term strong industries using industry capital flow and price changes, giving a specific verb, resource, and methodology. It doesn't explicitly distinguish itself from sibling tools like stock_sector_fund_flow_rank, but the combination of metrics is unique enough to be clear.
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?
No explicit when-to-use or alternative guidance is provided. The purpose implies a use case (finding short-term strong sectors), but there is no comparison with similar sector tools or notes on when to prefer this tool, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavior. It clarifies this is a read operation and lists returned data fields, but it does not disclose return ordering, limit semantics, or output structure. This is adequate but incomplete for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that concisely states the action, data content, and purpose. Every part earns its place with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool, the description covers what data is returned and the general use case. However, there is no output schema, and the description does not state that it returns the most recent N records or how results are ordered, leaving minor but relevant gaps.
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 100%, and both parameters have detailed descriptions with examples and suggested ranges. The tool description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (获取/get) with a clear resource (基金的历史净值数据/historical NAV data) and enumerates key fields (单位净值、累计净值、日增长率), which distinguishes it from sibling tools like fund_info, fund_holdings, and fund_ranking.
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 a general use case ('用于分析基金业绩表现') but no explicit when-to-use versus alternatives or exclusions. It does not mention that other fund tools serve different purposes, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral context. It only states the type of data returned with no mention of update frequency, data source, historical depth, or any other trait. The burden is not fully met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately states the tool's purpose and use case. No wasted words; concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides adequate high-level context but omits details about the return format or data granularity. Acceptable but with clear gaps.
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?
The schema already documents the single parameter with supported values at 100% coverage. The description adds no parameter-specific detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (获取) on a specific resource (仓单库存数据) for domestic futures, which distinguishes it from sibling tools like futures_positions (positions) and futures_prices (prices). The scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the intended use case '用于判断供需关系和价格走势', giving clear context on when to use this tool. However, it does not explicitly contrast with alternatives or mention exclusions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses data granularity (monthly) and included metrics (YoY, MoM), which is useful. However, it does not describe the return format, data source, rounding, or any behavioral quirks, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, front-loaded sentence that efficiently conveys the tool's purpose and data content without waste. Each phrase carries meaning, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one parameter, no output schema, no annotations), the description covers core functionality but lacks detail on output shape, time range behavior, and source. This leaves an agent relying on assumptions for return values.
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?
The schema already describes the single 'limit' parameter with a type and suggested range (12-60). The description adds no additional meaning for the parameter, so it stays at the baseline for full schema coverage.
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?
Description clearly states the tool retrieves China's monthly CPI data, including YoY and MoM rates, using a specific verb (获取) and resource (中国CPI月度数据). This distinguishes it from sibling macro tools like GDP or PMI, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context ('用于分析通胀水平' – for analyzing inflation), signaling when to use this tool. However, it does not explicitly state when not to use it or mention alternative tools, so it stops short of full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the data source (LPR) and tenors, but does not disclose whether the output is a time series, the data frequency, or any limitations. The 'limit' parameter suggests pagination but its effect is unexplained in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and includes the key tenor details. Every word contributes to the understanding of the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential purpose but lacks detail on the return format or historical nature of the data. The 'limit' parameter hints at multiple records, but the description does not clarify whether these are historical LPR values or something else.
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 100% for the single 'limit' parameter, which already includes a clear description in Chinese. The tool description does not add any additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches China's LPR (loan prime rate) data, specifically the 1-year and 5-year-plus tenors, for analyzing monetary policy and loan costs. This is a specific verb+resource combination and distinguishes it from sibling macro tools like macro_gdp or macro_cpi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use this tool (analyzing monetary policy and loan costs), but does not mention exclusions or alternatives. It implies the use case without explicitly naming when not to use it or comparing to other rate tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data nature (monthly, China, PMI, 50 threshold) but silently omits output format, ordering, historical scope, and how the limit parameter shapes results. As a read-only tool, risk is low, but behavioral ambiguity remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the main purpose and include the essential threshold context. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers the domain context well (PMI, 50 threshold), but it lacks any mention of return value structure, date range, or data source. Since there is no output schema, this gap leaves the user uncertain about what exactly they will receive.
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?
The single 'limit' parameter is fully described in the schema (integer, default 24, recommended range 12-60), achieving 100% schema coverage. The description adds no extra parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves China's Manufacturing PMI monthly data, specifying the exact resource (中国制造业PMI) and verb (获取). It also explains the 50 boom/bust threshold, and by naming PMI explicitly it distinguishes itself from sibling macro tools like macro_gdp and macro_cpi.
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?
The description implies the tool is for PMI data, but it doesn't explicitly mention alternatives or when-not-to-use. Siblings like macro_cpi exist for other indicators, yet no exclusions or comparisons are provided. The PMI interpretation context helps, but the 'when to use' guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says '获取数据' (fetch data) and gives a purpose, but does not describe output structure, data granularity, time range, or any operational constraints. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, and includes a brief purpose clause. No unnecessary words, repetition, or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description explains what it does and why it's used, but omits details about the return format, whether it is current or historical, and any limitations. It is minimally adequate but not fully complete.
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?
The schema fully documents the single 'metal' parameter, including default and allowed values, achieving 100% coverage. The description adds no additional parameter context. Per the rubric, the baseline of 3 applies when the schema is already descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (fetch) and the resource '贵金属期货与现货价格的基差数据' (precious metals futures-spot basis data), which is specific and distinguishes it from siblings like pm_spot_prices and futures_basis. The additional purpose clause ('判断市场预期和套利机会') further clarifies its intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case (market expectations and arbitrage opportunities) implying when to use it, but it does not explicitly mention alternatives or when not to use it. It lacks exclusionary guidance or a direct comparison with sibling tools, so it falls just short of full marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the included data categories and the one-shot composite nature ('一键获取'), but it does not explain how results are combined, whether all metals are always returned, or any latency/error behavior. The trailing '等' adds ambiguity about the exact scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the key differentiator ('复合技能') and efficiently lists the main data categories without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a good overview of the tool's main components for a one-parameter composite, but without annotations or an output schema it leaves gaps around return structure, data freshness, and behavior for unsupported inputs. It is viable but not fully complete.
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?
The input schema already covers the single parameter 'metal' with clear supported values (gold/silver) and a default, so schema coverage is 100%. The tool description adds no extra parameter-level meaning beyond the general mention of '贵金属'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('一键获取') and resource ('贵金属的价格走势、ETF持仓、COMEX库存、期现基差等综合诊断数据'), clearly stating it is a composite diagnostic tool. It distinguishes itself from sibling pm_* tools by aggregating multiple data categories in one call.
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?
The phrase '复合技能' and the enumerated data categories imply it should be used when a broad precious-metals diagnostic snapshot is needed in one call. However, it does not explicitly state when to prefer this over individual pm_* tools or mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It only states the purpose and does not elaborate on data source, update frequency, latency, or return format. For a read-only data tool this is a minor gap, but it still fails to provide any behavioral context beyond what is directly apparent from the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence that immediately communicates the verb and resource. It is front-loaded with the core action and adds the use case without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two simple parameters, no output schema, and no annotations, the description provides the essential purpose and use case. However, it does not specify what the returned data looks like (e.g., time series of changes, units, or date range), which could leave the agent uncertain about the response structure. Given the simplicity, a score of 3 reflects that it is adequate but lacks some detail.
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?
The input schema has 100% coverage with descriptions for both parameters ('limit' and 'metal'), so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides, so it neither improves nor worsens the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches global gold or silver ETF holdings change data, using the specific verb '获取' (fetch) and a precise resource. This distinguishes it from sibling tools like pm_spot_prices and pm_comex_inventory which focus on prices and inventories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the intended use case ('用于判断机构资金流向' – used to judge institutional fund flows), providing clear context for when to use this tool. However, it does not mention alternatives or when not to use it, so it slightly falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the output type (ASCII bar chart) and that it shows each position's P&L, but does not mention data source, whether existing holdings are required, or any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence that front-loads the action and output format. No filler or redundancy.
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?
Given the tool's low complexity (zero parameters, no output schema), the description is largely complete. It could be more explicit that it relies on an existing portfolio, but the term '持仓' implies current holdings.
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?
The tool has no parameters, so the baseline of 4 applies. The description adds context about what the chart represents, which is useful, though there are no parameter details to clarify.
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 clearly states the tool's function: generating an ASCII bar chart of portfolio profit/loss, with a specific verb ('生成') and resource (持仓盈亏的 ASCII 柱状图). It distinguishes from sibling tools like draw_ascii_chart by focusing on portfolio P&L, though it does not explicitly reference alternatives.
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?
The intended use is implied: use when you want a visual ASCII representation of position profit/loss. However, it provides no explicit guidance about when to prefer this over draw_ascii_chart or portfolio_view, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It implies a read-only 'get' operation but lacks details on permissions, data sources, return format, or limitations. The description does not contradict annotations (none exist), but it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose. It wastes no words and is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description is vague about what 'key indicators' are returned. It does not explain the output format or provide additional context that would help a user understand the tool's capabilities fully. It is minimally viable but lacks depth.
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 100% (the only parameter 'symbol' is described as '股票代码'). The description does not add extra meaning beyond the schema, but the baseline is 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches key indicators from US stock financial reports, using a specific verb (获取) and resource (美股市场的股票财务报告关键指标). It distinguishes itself from sibling tools like stock_indicators_a and stock_indicators_hk by explicitly scoping to US stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for US stock market financial indicators, providing clear context for when to use it. However, it does not explicitly mention alternatives or exclusions, such as 'for A-shares use stock_indicators_a'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It transparently lists the expected output fields (stock code, name, holding ratio), but it does not mention any potential limitations (e.g., data freshness, missing code handling) or explicitly confirm a read-only nature beyond the verb '获取'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that concisely states the action, resource, output scope, and purpose without any filler.
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?
This is a low-complexity tool with one optional parameter and no output schema. The description covers the main output fields and the use case, making it reasonably complete. It could mention that the parameter is allowed to be optional (since required is 0), but the schema already provides a default.
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?
The input schema already fully describes the 'code' parameter with an example (000001 华夏成长). The tool description adds no additional parameter context, so the baseline of 3 applies for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically states the action '获取' (get) and the resource '基金股票持仓明细' (fund stock holdings), which clearly distinguishes it from sibling tools such as fund_info or fund_nav. It also adds the analytical purpose '用于分析基金投资组合'.
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?
The description implies a usage context for portfolio analysis but does not explicitly contrast it with alternatives like fund_info, fund_nav, or fund_ranking. No when-to-use/when-not-to-use or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It discloses that prices are 'real-time' and lists covered instruments, which adds some behavioral context. However, it does not mention output format, potential delays, or error behavior. For a simple read-only getter, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the primary function and then adds specific examples. No filler or redundancy.
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 tool with one optional parameter and no output schema, the description plus parameter schema provide sufficient context. It explains the real-time nature and the covered instruments. It does not describe return structure, but that is not essential for such a simple price lookup tool.
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 coverage is 100%: the only parameter 'symbol' has a description enumerating supported values. The description text repeats the same list without adding new meaning. Baseline 3 is appropriate because the schema fully documents the parameter.
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 clearly states the tool fetches real-time international precious metals prices, listing specific instruments (London Gold, London Silver, COMEX Gold, COMEX Silver). This specifies the verb and resource. It does not explicitly contrast with sibling tools like pm_spot_prices, but the scope is clear enough to differentiate from most siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for international precious metals prices. There are no explicit exclusions or alternative recommendations, but the context implies when to use it. It does not explicitly say when not to use it, but that is not necessary given the narrow scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for disclosing behavioral traits. It only states the action ('获取' - get) and the data elements (P/E, P/B), but does not mention data source, update frequency, scope limitations, or any other behavioral characteristics. The verb implies a read operation, but that is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information without wasted words. It is front-loaded with the action and resource, making it easy to parse.
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, zero-parameter tool without an output schema, the description adequately communicates what the tool returns: an overview of Shenwan L1 industry valuations with P/E and P/B. It is complete enough for an agent to select and invoke the tool correctly, though it could benefit from mentioning the format or granularity of the overview.
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?
The tool has zero parameters, so the schema coverage is 100% and the baseline is 4. The description does not need to explain parameter semantics, and it adds meaningful context by specifying the exact metrics (P/E, P/B) the tool retrieves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('获取' - get) and resource ('申万一级行业估值' - Shenwan L1 industry valuation), explicitly mentioning the metrics (P/E, P/B). This distinguishes it from siblings like sector_rotation or stock_sector_fund_flow_rank.
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?
The description implies that this tool is for obtaining an industry valuation overview, but it does not explicitly state when to use it versus alternatives or any exclusions. No usage guidance is provided beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It explains the meaning of the scale ('0为极度恐惧，100为极度贪婪'), which is valuable context not present in the schema. However, it does not disclose the return format (e.g., whether it returns a single number or an object) or update frequency, but for a simple fetch tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('获取') and the resource ('恐惧贪婪指数'), then adds the scale explanation. No wasted words or unnecessary detail.
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 no-parameter, no-output-schema tool, the description is largely complete: it specifies the market (cryptocurrency), the index name, and the 0-100 scale. It lacks an explicit statement of the return format or update frequency, but these are not critical for a tool of this simplicity.
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?
The tool has zero parameters, so the schema is trivially fully covered. The baseline for 0 parameters is 4, and the description adds meaning by explaining the index range and interpretation, which is useful for interpreting the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it '获取加密货币市场恐惧贪婪指数' (retrieves the cryptocurrency market fear and greed index) with a specific 0-100 scale. The resource is distinct from sibling tools like crypto_sentiment_metrics, as it names a specific index rather than a general sentiment metric.
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?
The description provides no explicit guidance on when to use this tool versus alternatives. It only explains what the index measures, leaving the agent to infer usage from the tool name and context. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool focuses on main contracts and institutional rankings, but does not mention return format, data source, or update frequency. This is adequate for a simple read-only data fetch but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and includes the purpose. No wasted words.
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?
Given the tool's simplicity (1 param, no output schema), the description sufficiently covers the core functionality and purpose. It could benefit from clarifying what the ranking includes (e.g., long/short positions), but overall it is complete enough for the agent to understand the tool's role.
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 coverage is 100% for the single 'symbol' parameter, which already lists supported varieties. The description adds no additional parameter-level semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches institutional position ranking data for main futures contracts, using a specific verb (获取) and resource (机构持仓排名数据). This distinguishes it from sibling tools like futures_prices, futures_inventory, and futures_basis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: '用于判断主力资金动向' (used to judge main capital flow). This implies when to use the tool, though it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It describes the data type (monthly, M0/M1/M2, current value, YoY growth), which is helpful. However, it does not disclose potential quirks like data source, update frequency, or limitations beyond what the schema documents, leaving some room for assumption.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the resource and includes the purpose. There is no redundant information or filler.
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?
Given the tool's simplicity (one optional parameter) and lack of output schema, the description sufficiently covers the key return values (current value and YoY growth) and frequency. It could specify the response format in more detail, but it is nearly complete for this straightforward data retrieval tool.
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?
The schema description covers the sole parameter (limit) fully, including a recommended range. The tool description does not add meaningful extra semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves Chinese money supply data (M0/M1/M2) on a monthly basis, including current values and year-over-year growth rates. This clearly names the resource and differentiates it from sibling macro tools like macro_gdp or macro_cpi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: for analyzing monetary policy and liquidity. It does not explicitly mention when not to use it or alternatives, but the mention of '货币政策和流动性' gives sufficient guidance given the tool's specific scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the read-only nature ('查看' = view) and purpose, which is transparent, but it does not detail the return format, potential size, or any side effects beyond the implied read-only behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence: '查看当前缓存的键和数量，用于调试和监控'. It is front-loaded with the action and resource, with every word contributing to the meaning, and no redundant wording.
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?
Given the tool's low complexity (no params, no output schema), the description sufficiently explains what it does and why. It could specify the output structure (e.g., keys list vs. count object) but the current scope is acceptable for a simple status tool.
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?
The tool accepts zero parameters, so the schema already fully covers parameter semantics. The description adds no parameter details because none exist, which is appropriate. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '查看当前缓存的键和数量' (view current cache keys and count). This is a specific verb+resource, and it differentiates from siblings like cache_clear by focusing on status observation rather than mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says '用于调试和监控' (for debugging and monitoring), providing clear context on when to use it. It does not explicitly name alternatives or exclusions, but the context implies this is for read-only inspection, distinct from cache_clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys a safe read-only operation and indicates the output includes system time and A-share trading day information, but it does not specify timezone, return format, or the exact content of '交易日信息'. Basic transparency is present, but richer details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: it first states the main function, then gives a practical usage recommendation. There is no filler or redundant content, making it highly concise and well-structured.
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?
The tool is simple with zero parameters and no output schema, so the description does most of the work. It clearly explains the purpose and implies the output can be used as a date parameter for other tools, though it does not explicitly define the return structure. Given the low complexity, this is adequately complete.
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?
The tool has zero parameters, and the input schema is an empty object, so the description need not document parameter syntax. The baseline for zero-parameter tools is 4, and the description adds a useful hint that its output can be used to fill date parameters in other tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '获取当前系统时间及A股交易日信息' (get current system time and A-share trading day information). This is a specific verb+resource combination that distinguishes it from sibling market-data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool before calling other tools that require date parameters ('建议在调用其他需要日期参数的工具前使用该工具'). This provides clear usage context. It does not list exclusions or alternatives, but the recommendation is strong enough for a utility tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context: '不支持加密货币' (cryptocurrencies not supported) and '比较耗时' (relatively time-consuming). However, it does not disclose the return format or how results are presented (e.g., single code vs. list), which is important for a search tool without an output schema. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that front-load the core purpose and immediately follow with actionable usage guidance. Every clause adds value—the first sentence states function and limitation, the second explains when to avoid the tool. No wasted words or redundant information.
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?
Given the tool's simplicity (2 params, 1 required, no output schema), the description covers the key aspects: purpose, scope (no crypto), performance, and selection guidance. The only notable omission is an explicit statement of what the tool returns (e.g., a list of matching stock codes), but this is strongly implied by the title and purpose. Overall, near-complete for this low-complexity tool.
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?
The input schema already covers both parameters with 100% coverage: 'keyword' is described as requiring company/stock names or codes, and 'market' is fully documented with allowed values. The tool description restates '股票名称、公司名称等关键词', duplicating the keyword schema. It adds no new parameter-specific meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '根据股票名称、公司名称等关键词查找股票代码' (find stock codes based on keywords such as stock/company names). It uses the specific verb '查找' (find) and names the resource '股票代码', distinguishing it from sibling tools that operate on already-known codes. The explicit exclusion of cryptocurrencies further clarifies its scope relative to crypto-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: '该工具比较耗时，当你知道股票代码或用户已指定股票代码时，建议直接通过股票代码使用其他工具' (This tool is time-consuming; when you know the code or user has specified one, directly use other tools with the code). This tells the agent when to avoid the tool and to prefer alternatives, making the decision clear, even though it doesn't name specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![aktools-pro MCP server](https://glama.ai/mcp/servers/tchivs/aktools-pro/badges/card.svg)](https://glama.ai/mcp/servers/tchivs/aktools-pro)

Score Badge

Copy to your README.md:

[![aktools-pro MCP server](https://glama.ai/mcp/servers/tchivs/aktools-pro/badges/score.svg)](https://glama.ai/mcp/servers/tchivs/aktools-pro)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tchivs/aktools-pro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server